Nathan Torkington wrote:
> 
> *tap* *tap* is this thing on?

<squeal> <screeech> <whizzzzz>

(lame attempt at a "feedback" joke - ha ha)

Like others, I'm amazed. It looks like Perl 6 is going to be incredibly
coherent, despite the RFC frenzy. For now I have mainly compliments, and
a few thoughts:


1. Breaking @foo vs. $foo[]

This is interesting, and in my gut I like it. Many people I've worked
with end up writing:

   @foo[0]

Which works. But then, they're completely confused by why:

   %foo{key}

Doesn't. Sure, RTFM, but when so many people have the same issue then
sometimes it's indicative that you may be able to improve it. Something
better would be cool. I'm looking forward for Apoc2 for more on this and
highlander variables. I really hope Larry looks into RFC 134
(alternative array and hash slicing).


2. package vs. module/class

Whoa. This is so simple yet so sublime. It solves so many issues in one
swoop. Cool.

Assuming Perl6 will be parsing Perl5 code? Hmmm. That's interesting.
Forget p52p6 and the whole 80/20 thing, we could potentially hit the
100% mark. I wonder, implementationally, if to keep Perl6 light
Configure could ask "Path to Perl 5?" and then fork the Perl5
interpreter (instead of doing this natively). Maybe this is thinking too
far ahead.

I'm unsure about the "module main" idea. I like that modules as a whole
are strict/-w by default. But the "module main" tag causes the same
problem Larry is opposed to with BASIC/PLUS "EXTEND". That is, every
Perl 6 program begins with "module main". Maybe there's a better way to
implement this? ("use 6.0" has much the same problem)


3. Core functions return objects (RFC73)

Woo-hoo! :-) I hope this works out. I really like Larry's preliminary
take on this. The key seems to be making objects as fundamental and
lightweight as possible. Otherwise, if they're too heavy then Perl gets
really slow, and I don't think anyone wants that.

Since submitting this RFC, I've been pondering. Perhaps it could be
turned on by:

   use objects;

Or, it could be on by default and disabled by:

   no objects;

So, the person who really needed that extra speed advantage could say
"no objects" and get it. I don't see how this could be lexical though,
and it seems to have to be known at startup time, so it might need a
switch ala -T.  But then again if there's a native Perl struct that's
really fast, then this is probably unnecessary.

-Nate

Reply via email to