On Wed, May 04, 2005 at 10:58:22AM -0400, Rob Kinyon wrote:
: I just started following the list again after a few months (though I
: have been skimming the bi-weekly summaries) and I'm a little alarmed
: at what seems to be a trend towards operaterizing everything in sight
: and putting those operators in the core.

I think your concern is overblown here.  Yes, it's a slippery slope.
No, we are not sliding all the way down it.  And it's just as easy
to slide up this slope as well as down, and end up with Lisp rather
than APL.  Neither extreme is healthy.

Are there any particular other operators you're worried about?
I think the current design does a pretty good job of factoring out the
metaoperators so that the actual set of underlying basic operators *is*
relatively small.  Yes, you can now say something like

    $x = [+^=] @foo;

but the basic operator there is just ^, with a + modifier to indicate
numeric XOR, = to indicate an assignment operator,  to indicate
explicit paralellism, and now [] to indicate reduction, all in a nice
visual pill so you can think of it as a single operator when you want
to.  But I didn't even think about adding a reduction metaoperator till
I wanted it for something else in the design that had been bugging me
for a long, long time.  Almost nothing in the design of Perl 6 is there
for a single purpose.

: My understanding of P6 after the reading the AES was that the core was
: supposed to be very small, robust, and reusable.

Eh, I don't think that was ever a major goal after the RFCs came out.
After the RFCs it soon became apparent that we had to figure out at
least one obvious way to do most of these things, or people would just
reinvent several incompatible ways.  The main design goal is to find
an impedance match between the problem space and the solution space,
and that means some kind of middling approach to complexity.

: The biggest feature
: was supposed to be the PGE, from which you could define anything you
: wanted as an add-on module. Kinda like Lisp, but Perlishly dwimming.

Again, even with rules we're aiming at a combination of simplicity
and power.  We have not hesitated to add notation where it clarifies.

: What happened to the idea of having modules that define syntax? Did I
: miss a change in focus over the past few months?

Nope.  You can still warp syntax as much as you like.  But we'd like
to discourage people from doing that by default merely because the
core neglects to provide a standard default solution.

That was the big problem with Perl 5's OO design.  It was too minimal.
It didn't specify an obvious way to do it, so everybody rolled their own
in an incompatable fashion.  We're not going so far as Python philosophy,
where if there's an obvious way to do it, you disallow any other solutions.
But if you oversimplify the core, you force the complexity elsewhere.
It's just the Waterbed Theory of linguistic complexity.  Push down
here, it goes up there.

In short, it's still the very same old "Easy things should be easy,
and hard things should be possible."  It's just that with Perl 6, we're
rethinking what should be easy, and what should be merely possible.
Most things are nailed down by now to one side or the other, but
now and then something flips over to the other side.  And last night
I decided that reduce should flip to "easy", especially since it's a
really easy metaoperator to explain to a newbie.  (Much easier than
the +, ~, and ? bitop prefixes that people nonetheless seem to like,
for instance.)

Larry

Reply via email to