On Mon, Jan 12, 2009 at 02:43:37PM -0800, Ovid wrote:
: Actually, I'd prefer to go much further than this:
:
: use Core 'MyCore';
:
: And have that override core classes lexically.
We're already speccing a way to substitute a different prelude from
the command line, in order to desugar -n and -p switches. There could
certainly be a use-ish way to do that too. And maybe "substitute"
is the wrong concept here. It probably needs to be nestable, so that
we are installing an additional lexical wrapper outside the current
scope, but inside whatever the previous prelude scope provided.
Maybe call it "underriding" instead of "overriding". :)
So given something like:
#!/usr/bin/perl6 -p
use prelude MyPrelude;
Then OUTER of MyPrelude might be a -p looping scope, and OUTER of the
-p scope might be the standard Perl 6 Prelude. And this happens a
compilation time, so the compiler knows while it's parsing that any
reference to Array mean MyArray, including any implicit references.
The mechanism by which we freeze a snapshot of the language (nice
mixed metaphor there) for the prelude is also the mechanism by which
we freeze a snapshot so we know what language eval() defaults to.
It doesn't default to standard Perl 6, but rather the language existing
at the moment the eval is compiled, which might have little resemblence
to standard Perl 6.
I really do believe in lexically-scoped language mutations: it's
not just a bullet point--it's what Perl 6 is Really All About, in
my ever-so-humble opinion. To make that work right, every part of
your lexical scope needs to know *exactly* what language it's in,
including the parts that are intentionally inexact; any parts of
the language that are generic need to be explicitly parameterized,
not nebulously defined by some environment variable or by some rc
file or even by the current perl implementation.
As far as I'm concerned, everything else about Perl 6 is a bikeshed in
comparison, because everything else about Perl 6 can change gracefully
over time if we get this part right. The current lexical context
determines the types that are visible, as well as the multimethods
that are visible on those types, including the operations used to
parse and mutute the language itself. Seems simple enough... :)
Larry
