On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote: > 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.
But the compiler needs to trigger ambiguity resolution -- i.e. check
for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
No need to do that if it sees $_.method. So they need to be different.
> 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 $_.
The problem here is for the compiler to detect whether $_ agrees
with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
$?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
Consider this construct:
method foo {
$_ := $something_else if rand(2)>1;
.bar;
}
That's one case where it's not possible to detect at compile time,
so it needs to silently let .bar go thru as $_.bar.
> : 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:
But what in "given" and "for" signify that? I do not want to special
case based on function names, and &statement:<given> may be rebound
to something else. How does that something else signify that it will
at least bind at least one argument to its code argument? Via the
signature of the code argument, i.e. the <Any> in &code<Any>?
sub statement:<given> (Any $topic, &code<Any>) { ... }
If so, what is the signature of "for"? I can't seem to write it down.
> : 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.
>
> 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.
Yes, that's the main difference. How does the :my<> form of export work
in the exporter's end?
sub foo is export<my> { ... }
Will that work?
> : 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...
Indeed I suspect both are true. :)
Thanks,
/Autrijus/
pgpUx78e7n7vf.pgp
Description: PGP signature
