On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
The parser always emits .method as $_.method under any dialect, or
fails. What has changed is whether $_ sometimes means the invocant.
: If it is
: not set, the parser needs to emit this as the first statement in any
: method body:
:
: $_ := $?SELF
That is the part that has to be conditional on the dialect.
: The compiler, in turn inspect whether there's an bound $_ in scope
: with $?SELF set. It is not trivial, because this should work:
:
: sub baz (&c) { c() }
: method foo { baz { .bar } } # $_ is free in inner closure
:
: But this needs to fail:
:
: sub baz (&c) { c(1) }
: method foo { baz { .bar } } # $_ is bound in inner closure
The compiler is free to treat any undecidable binding as ambiguous
and die of uncertainty. Though we should probably make some official
rule so that different compilers don't end up with different definitions
of "undecidable".
In any event, SMD methods always have a first argument, so you're never
in doubt at that point. And since .bar always means $_.bar, I don't
think you really have a problem here that's any harder than you already
had with $_.
: Clearly we need a way to statically determine &statement:<given>
: and &statement:<for> will always assign at least one argument to
: its block argument. Without that, the compile-time analysis mandated by
: Larry is infeasible.
I think you can assume that "given" and "for" always bind at least one
argument. In particular, a "for" that binds 0 arguments will never
progress, plus you can recognize it:
for @foo -> {...}
And a given that doesn't bind $_ isn't worth much either.
Or is that what you're asking?
: Then, we need to figure out the structure for the magic flag set by
: self.pm on behalf of its caller. We are not using $^H anymore, so
: there needs to be a way to pass lexical settings to the caller.
Perhaps hints should just be considered lexically scoped $? variables.
You export them lexically just the same way you export any other lexically
scoped things, however that is.
: To use MJD's lexical pragma design:
:
: module self;
: use pragma;
: sub import ($caller, $dialect) {
: install_pragma_value('$?SELF_MAGICAL', $dialect);
: }
:
: This will create a lexically scoped hint in the importer's scope;
: the parser and compiler will be hard-wired to recognise that magic
: and act accordingly.
How will you handle:
use Foo :my<$x>;
Seems like this is just a kind of
use Foo :my<$?MYHINT>
thingy, only perhaps you're just setting $?MYHINT rather than aliasing
it back into a Foo variable.
: Does this seem sane? The static detection of $_ is the showstopper
: currently, and Pugs will need to separate the compiler with PIL evaluator
: to implement the pragma.pm above.
I suspect you're making it complicateder than it needs to be, but
perhaps I don't understand the problem fully. Of course, the two are
not mutually exclusive...
: Before that happens, I'll still pretend that:
:
: use self './';
:
: is in scope. If people are uncomfortable with that, maybe we can
: retrofit all tests and examples using the ./ syntax to add that dummy
: line on top of their code, and ship with a stub self.pm that does
: nothing. Will that do as a interim solution?
That's fine for the short term.
Larry
