Edwin Wiles wrote:
> Maintainer Statement:
> Okay, I've added a note that wholesale adoption of C structure
> definitions, with appropriate modifications, has been suggested.
> However, if you really want it seriously documented, you'll have to
> write it up.
I did. Three or four times. And I am vocal about this point of view
(that perl6 should be a proper superset of C) in list discussions.
> I've included an updated copy of the RFC. If you approve of it, and
> want it out there for discussion immediately, I'll submit it to the
> librarian. OTOH, if you want me to wait until you have the definition
> written, I'll do that too. (Unless other critical revisions come in.)
>
> Personal Opinion:
> I am against it not only because of it's native lack of critical
> features, but because it would effectively include the C structure
> parser into Perl. Given that we have parser capability that can already
> handle the problem, I see no reason to include yet more parser
> capability, which would be highly specific to a given problem.
> Where, other than in pack/unpack, would we be using C structure
> definitions?
in defined types for polymorphism, for tighter interface with existing
C libraries, in structure definitions. In designing fast objects
that can use their own native storage rather than baing hacked onto
hash arrays.
> As it is, the definitions are all in terms that are easily
> handled by the existing parser. The type specifications, to the
> existing parser, are simply strings. Understanding those strings can be
> isolated in the pack/unpack code, rather than in the main parser.
limiting it to a smaller arena doesn't make it any smaller, if we have to
solve it we might as well solve it generally
> Given C structures, unless they're simply presented as multi-line
> strings, would require extensive additions to the main parser. If they
> are presented as multi-line strings, then we have a fairly large
> auxiliary parser built into the pack/unpack code. Without additional
> justification, I don't like either alternative.
>
> Edwin
> =head1 TITLE
>
> Enhanced Pack/Unpack
>
> =head1 VERSION
perl5 has several different structure definition languages too,
it has protopye declarations and pack formats. Okay, two is not
several.
If we combine both of them into one, and extend it, that's what
I want to do, as RFC'd in (my) 61, 75, alluded to in 15 (any time
you have a type you can tie to it, this would work with a structured
type) all the things you can do with the types listed in 89 could be
done with the userdefineid types, then there's 122 which says "we use
C structures."
So no, Edwin, I'm not going to write another RFC because you haven't
read the four I wrote already stating this. (And stating that pack/unpack
should take a structure definition instead of or as part of its format
specifier.)
--
Safety first! Republicans for Nader
