p6apclps #12 Perl 6 Apocalypse

http://www.perlfoundation.org/perl6 - - of the standard input filehandle is $*STDIN, but a package may just refer to $STDIN, and it will default to $*STDIN if no package or lexical variable of that name has been declared. [Update: We did s/ STD// on those, so standard input is now just $*IN.] Some of these special variables may actually be cloned for each lexical scope or each thread, so just because a name is in the special global symbol table doesn't mean it always behaves as a global across all modules. In particular, changes to the symbol table that affect how the parser works must be lexically scoped. Just because I install a special rule for my cool new hyperquoting construct doesn't mean everyone else should have to put up with it. In the limiting case, just because I install a Python parser, it shouldn't force other modules into a maze of twisty little whitespace, all alike. Another way to look at it is that all names in the ""*"" package are automatically exported to every package and/ or outer lexical scope. [Update: The names are no longer automatically exported, but you can import them from the global namespace via ""use GLOBALS '$IN', '$OUT';"" and such.] Literals Underscores in Numeric Literals Underscores will be allowed between any two digits within a number. RFC 105: Remove "In string @ must be \@" Fatal Error Fine. [Update: The interpolation rules for arrays have been completely revised. A bare array name no longer interpolates--you have to say @foo[].] RFC 111: Here Docs Terminators (Was Whitespace and Here Docs) Fine. RFC 162: Heredoc contents I think I like option (e) the best: remove whitespace equivalent to the terminator. By default, if it has to dwim, it should dwim assuming that hard tabs are 8 spaces wide. This should not generally pose a problem, since most of the time the tabbing will be consistent throughout anyway, and no dwimming will be necessary. This puts the onus on people using nonstandard tabs to make sure they're consistent so that Perl doesn't have to guess. Any additional mangling can easily be accomplished by a user-defined operator. [Update: Here docs are now just a :to variant on extensible quotes, so any customization you can do to "q/foo/ " you can also do to "q:to/END/". RFC 139: Allow Calling Any Function With a Syntax Like s/// Creative quoting will be allowed with lexical mutataion, but we can't parse "foo(bar)" two different ways simultaneously, and I'm unwilling to prevent people from using parens as quote characters. I don't see how we can reasonably have new quote operators without explicit declaration. And if the utility of a quote-like operator is sufficient, there should be little relative burden in requiring such a declaration. The form of such a declaration is left to the reader as an exercise in function property definition. We may revisit the question later in this series. It's also possible that a quote operator such as "qx/ /" could have a corresponding function name like "quote: qx" that could be invoked as a function. RFC 222: Interpolation of Object Method Calls I've been hankering for methods to interpolate for a long time, so I'm in favor of this RFC. And it'll become doubly important as we move toward encouraging people to use accessor methods to refer to object attributes outside the class itself. I have one "but," however. Since we'll switch to using "." instead of "-]", I think for sanity's sake we may have to require the parentheses, or ""$file.$ext"" is going to give people fits. Not to mention ""$file.ext"". [Update: Nowadays we also require brackets on array interpolations and braces on hash interpolations. See S03 for more.] RFC 226: Selective Interpolation in Single Quotish Context. This proposal has much going for it, but there are also difficulties, and I've come close to rejecting it outright simply because the single-quoting policy of Perl 5 has been successful. And I think the proposal in this RFC for "\I"..."\E" is ugly. (And I'd like to kill "\E" anyway, and use bracketed scopings.) However, I think there is a major "can't get there from here" that we could solve by treating interpolation into single quotes as something hard, not something easy. The basic problem is that it's too easy to run into a "\$" or "\@" (or a "\I" for that matter) that wants to be taken literally. I think we could allow the interpolation of arbitrary expressions into single-quoted strings, but only if we limit it to an unlikely sequence where three or more characters are necessary for recognition. The most efficient mental model would seem to be