I haven't seen it mentioned here yet, so for those who haven't noticed A3 is now out: http://www.perl.com/pub/a/2001/10/02/apocalypse3.html
There's a lot to like here. I'll just cover 2 points for now though... Larry's discussion of RFC 082, while not quite complete, does a great job of learning from APL/J's heritage while incorporating the greater flexibility of Perl. > Anyway, in essence, I'm rejecting the underlying premise of this RFC, > that we'll have strong enough typing to intuit the right behavior without > confusing people. Nevertheless, we'll still have easy-to-use > (and more importantly, easy-to-recognize) hyper-operators. Really the underlying premise of the RFC was that hyper-operators (nice term!) are a good idea, and that Perl should support them. I'm very happy with the idea that hyper-operators require an extra symbol, and it gets around the conflict with RFC 045 nicely too :-) But... earlier messages from Larry suggested that the hyper-operator symbol would actually be an adverb (back then ':' was being proposed, IIRC), which sounded even more exciting... Is this still the plan, with more to come in later apocolypses about other adverbs (a table adverb?, conjunctions?), or has the whole adverb thing been scrapped? > The binary ; operator separates two expressions in a list, much like > the expressions within a C-style for loop. Obviously the expressions > need to be in some kind of bracketing structure to avoid ambiguity > with the end of the statement. Depending on the context, these > expressions may be interpreted as arguments to a for loop, or slices > of a multi-dimensional array, or whatever. In the absence of other > context, the default is simply to make a list of lists What's wrong with the default cartesian product behaviour specified in: http://dev.perl.org/rfc/205.html ? As described in RFCs 202-207, this behaviour provides flexible slicing of multi-dimensional arrays. The default proposed in A3 on the other hand doesn't seem to provide much of a win at all, other than saving a couple of key strokes for creating a list-of-lists. Maybe Larry has got a new grand plan for the whole multi-dimensional array thing which makes RFC 205 obsolete... but in the absense of knowing the ineffable plan I can only argue on the basis on the RFCs and apocolypses that are available...
