> I'd thought I try to summarize what has come up so far and see if we can
> find somebody who can write some RFCs.
>
Terrific--thanks!
Make sure you read the interesting RFCs from Damian Conway on related
issues:
> * Built-ins: min() and max() functions and acceptors
>
> * Built-ins: reduce() function
>
> * Data structures: Semi-finite (lazy) lists
>
> * Subroutines: higher order functions
>
> * Subroutines: lazy evaluation of argument lists
>
> * Superpositions: vector operations via superpositions
He's also promised general purpose iterators in a separate message. These
haven't all been written yet.
The excellent news is that Dan Sugalski (who's heading up the internals
team) has promised that he'd make sure that the optimisations we need would
be seen to. In particular, we talked about making sure that the following
creates only one loop and no array copies:
$a = sum(@b*@c+@d)
...and I did point out that @b et al might actually be columns of a sparse
matrix accessed through an iterator.
>
> > Larry Wall will decide the changes to make for perl6 based on our
> > suggestions. To make life easy for him, we should put some effort
> > into our suggestions. RFCs are intended to be focus discussion on
> > something that will be useful to Larry when he makes his decisions.
>
> This reads to me like the code of this religious cult whose aim it is to
> worship the great LW.
>
>From perldoc perlhack:
You might sometimes see reference to Rule 1 and Rule 2.
Larry's power as Supreme Court is expressed in The Rules:
1 Larry is always by definition right about how Perl
should behave. This means he has final veto power on
the core functionality.
2 Larry is allowed to change his mind about any matter
at a later date, regardless of whether he previously
invoked Rule 1.
Got that? Larry is always right, even when he was wrong.
It's rare to see either Rule exercised, but they are often
alluded to.
Under this premise Larry is well placed to make a final ruling ;-) In
reality he respects the opinions of people like Damian Conway, Dan Sugalski
a great deal and is unlikely to just through out stuff they suggest.
But the nice thing about having one person responsible for oversight is that
he can pull disparate threads together into a unifying construct. Larry has
shown in the past that he is very good at this.
> I am not sure if this impression is intended but I notice a lack of
> clarification how the syntax issues about perl6 are decided. Is it
> really all down to one individual (however bright and charismatic this
> particular person may be)? A more clearly stated process where possibly
> a small group of developers (with write access to the repository)
> decides things and where a project leader (LW?) has the possibility of a
> veto or such seems at least transparent to me. It would probably also be
> welcomed by industry if a clear process is outlined.
>
There was a lot of discussion on the bootstrap list about how this should
all work. I don't think there's much chance of getting a rethink at this
stage.
> Maybe I am the only one seeing a possible problem here but as a
> scientist I am deeply suspicious about a decision process that is down
> to one individual only (not even taking the workload into account).
>
Larry's workload will be greatly dimished by the working group chairs, who
pull together the RFCs for him. In turn the RFC chairs pull together the RFC
threads for the WG chair. So far this process is looking like working pretty
well. As Plato pointed out, a benevolent dictator is the most efficient form
of government...
Anyway, all I can say is, give it a go! Start cross-posting your thoughts to
perl6-language, and pop over to dev.perl.org to see what RFCs are around.
I'm sure you want to keep up the discussion with PDL-P, but if it's about
perl 6, why not have it on perl6-language where everyone can follow it?
