S29 problems and plan/TODO
Aaron Sherman
fixed. So, on to the good stuff....
I've been consumed by work for a while, but every time I return to the
S29 work I have the same problem: p6l is a constantly bubbling cauldron
of ideas, proposals, decisions, reversals, modifications, etc. My list
circa earlier this year of "top priority" messages that needed to be
incorporated was long, and over the summer and early fall it has grown
substantially, and I haven't even had the time to fully compile a TODO
list before it becomes obsolete.
If I'm to finish this, I have to draw a line in the sand, and say,
"these are the dates of authority, and these are the people who I'm
going to pay attention to."
I thus propose 2005-03-16 (last Rod Adams update) - 2005-10-17
(yesterday, yes that's arbitrary) on the mailing list and pugs/ext from
svn as of revision 7682 as the inputs for the next revision of S29. I'll
compile a TODO list based on that range and produce a new draft of S29.
As for who: I intend to take any proposed modification to existing Perl
5 builtins, the builtins that are already in S29 and a select few others
that seem to be intended for such a document from any of the following
(and, of course, from anyone that the following people responded to in
favor of such a proposal):
Luke Palmer <lrpalmer@...>
chromatic <chromatic@...>
Nicholas Clark <nick@...>
Larry Wall <larry@...>
Autrijus Tang <autrijus@...>
Brent 'Dax' Royal-Gordon <brentdax@...>
Chip Salzenberg <chip@...>
Damian Conway <damian@...>
That seems like a suitably long list of messages to grovel through
(around 900).
Before I re-re-embark on this task, does anyone have any comments or
concerns?
Some thoughts for digestion:
* S29 as it stood last has made several assumptions about the
nature of the type/object system that will accompany it. As a
second and third pass, it will probably make sense to create a
separate document that lays out the core types/classes that S29
needs and then to come back and revise S29 to reflect the
changes that were required.
* As stated previously, the line between operators and builtin
functions in P6 is blurry.
* Note that A14, A16 and A17 currently block the resolution of
some issues (see the Pending Apocalypse section of the current
draft).
If someone would give me commit rights on the pugs svn, I'll probably
fork a separate "docs/AES/S29draft.pod" as "docs/AES/S29working.pod" so
that others can actively collaborate rather than just waiting for a
final product, and replace the draft once it's actually in a consistent
state. Otherwise, I'd have to muck around with branching, and I'd rather
not.
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Aaron Sherman
> I thus propose 2005-03-16 (last Rod Adams update) - 2005-10-17
> (yesterday, yes that's arbitrary) on the mailing list and pugs/ext from
> svn as of revision 7682 as the inputs for the next revision of S29
s{pugs/ext}{pugs/t/builtins} for the most part, though some items in
pugs/ext are germane. Sorry about that slip-up.