Note that I am not subscribed to perl6-language-data, and that all the prior
discussion of
this RFC took place on -language. Perhaps it is better classified under -data, but
that's
not its present discussion list, according to the RFC.
"David L. Nicol" wrote:
> Glenn Linderman wrote:
>
> > Edwin's arguments against the idea seem reasonable; I think it would take some
> > compelling benefit to invest in implementing a C type & structure parser in perl,
>for
> > this use. Further, the C syntax doesn't provide for explicitly sized types, and
>what
> > would you do with C's pointer types, which have no equivalent in Perl? If the
>benefit
> > was intended to be "can import any C structure as documented" you can't, because of
> > pointer issues, and C++ object model mismatch.
>
> You don't see transparency between Perl and C as a "compelling benefit?"
Attempting to parse the syntax of a small subset of legal C data structures wouldn't
provide
transparency between Perl and C, for my definition of transparency. This type of
feature
would be best done, IMHO, as a standalone utility program, that converts C structure
syntax
to appropriate parameters for Perl Structure. Such a utility could be written in C, or
written in Perl, could be written using some preexisting parser tool with an included
parser
for C/C++ syntax, or however. You could even do reverse translations from Perl to C.
Do you have any references to any other computer language that imports declarations
from a
different computer language? i.e. is there prior art that demonstrates this as a "good
thing", and if so, what were the realized benefits?
The closest thing of which I am aware are IDL languages that can, from their own
syntax,
emit the "equivalent" data structures in multiple languages for a given platform. I
would
have no objection to ensuring that RFC 142 provides sufficient facilities to allow
such an
IDL language to emit Perl Structures. As far as I can tell, it already does, and
more, but
I may be overlooking something.
> perl5 references and C pointers are very similar things, the fact that
> they are not more closer equivalents annoys some C programmers who find
> writing perl to be like sprinting in swamped waders: you can do it but
> its awfully squishy.
Using pointers vs using safer constructs makes large divisions among programmers.
Such a
shift would seem to be a major change from current Perl philosophy.
> If we're doing a "complete rewrite" then the equivalency can be designed
> in from the beginning rather than "bolted on" That's the whole point of
> this conference isn't it? Or is it just to sell more O'Reilly books.
That's far beyond the scope of RFC 142, IMHO. For this sort of equivalency, we'd need
a
much bigger RFC, and should it fly, and include the ability to parse C data
structures, we
could just sort of throw RFC 142 away, methinks. But if no one goes that far (and so
far,
in 150 some RFCs, no one has, feel free to write it), then RFC 142 could provide some
useful
benefit, not just for simple C data structures, but also for simple Pascal, Basic,
Forth,
Modula, Scheme, Python, ... data structures.
> --
> David Nicol 816.235.1187 [EMAIL PROTECTED]
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
