Nicholas Clark:
# On Fri, Mar 01, 2002 at 05:17:28AM -0800, Brent Dax wrote:
# > After banging my head against a wall for a few hours with
# Perl 5's XS, I
# > have an idea for how Parrot can do it better.
# >
# > Basically, the big problems with XS are:
# > -It's ugly as hell
# > -It makes the extender do tons of extra work
# > -It seriously munges your code
#
# And just like python it attaches significance to whitespace.
# [Is this a problem or a feature?]
#
# > Here's an example of my proposed format.
# >
# > /* optional */
# > parrot_xs {
# > xs_version => 0.1,
# > parrot_version => 0.0.3
# > };
# >
# > #include <math.h>
# >
# > /* not sure if we need this */
# > module {
# > name => Math::Round,
# > version => 1.0.3
# > };
# >
# > extern int floor(double);
# > extern int ciel(double);
#
# It confused me at first. Conceptually it seems that there is
# a sudden jump
# from perl syntax to C syntax, without any visual alert marks.
# Reading it again I few times I realise that the above is
# (almost) C syntax,
# apart from the => and the V string, but I'm still not sure if
# I like this
# hybrid that isn't quite either.
I think we have to leave the vstring in place, but we can probably do
something instead of the arrows. 'xs_version(0.1)'?
# > I'm sure other people have ideas on this. Let 'em fly--the more the
# > merrier.
#
# Do we have a "spec" of things we like about XS (apart from
# typemaps), things
# we don't like, things we like about Inline, things we don't like, and
# things we'd like to have that aren't in either?
Dan's opinion seems to be "let them fend for themselves"--XS functions
should decode their own arguments.. I don't agree with that, but he's
the internals designer, not me.
--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking, regex hacker, embedding coder, and boy genius
#define private public
--Spotted in a C++ program just before a #include
