On Wed, Mar 19, 2003 at 10:34:26AM +1100, Damian Conway wrote: : Brent Dax wrote: : : >First of all, Larry, do you have *any* idea how difficult you're making : >my life? :^) This stuff is damn hard to implement--I'm at 450 lines : >and counting, and I haven't even started the semantic analysis stuff, : >let alone *tested* anything.
Yes, I think I understand that. But please understand that you're suffering vicarious pain for the user. (We sincerely hope.) I'll be interested to get feedback on spots where the design impacts performance unnecessarily, such as preventing optimizations we might otherwise do. : At least I have Filter::Simple's : >FILTER_ONLY and P::RD to help me--without them, I'd be lost. Thanks, : >Damian! (Perl 6 regexes map pretty well onto P::RD, but then I guess I : >should consider the source. :^) ) : : Just wait till you see P::RD's successor: Perl6::Rules ;-) Funny thing is, I never looked at P::RD before doing A5 (hangs head in shame), so think of it as convergent evolution in action... : >Anyway, a couple questions as I rework and extend Perl6::Parameters: : > : >-A6 mentions that unprototyped subroutines get their arguments in @_. : >It also says that methods get their invocant in $_. In an unprototyped : >method, is the invocant in $_, @_[0], both, or neither? : : The invocant is bound to both. Hmmm. I'm not so sure. I can argue it both ways. Sure, it's nice to be able to attach an absolute rule to "method", but I'm inclined to think that unsigged methods work a little more like Perl 5 in that case, and just put the invocant (or rather leave the invocant) in @_[0]. This might simplify the translator. But if were just methods, I'd wouldn't make an exception. But I'm wondering if there is another general rule that supercedes method topicalization. We could have a policy that all *sigless* sub declarations just treat $_ as an external lexical variable, rather than the A6 policy of implicitly declaring an undefined $_. This would have the beneficial effect (from the standpoint of p5-to-p6, anyway) that most sigless subs default $_ to file-scoped $_, and a great deal of the Perl 5 code that treats $_ as dynamically scoped would still work, as long as the caller and callee were sharing the same file-scoped $_. A file-scoped $_ could be considered a sort of a half-way house to full signatured $_ semantics. You couldn't clobber some other module's $_, but you still get a dynamically scoped $_ where naive users expect it. It's not a beautiful solution, but it might make the migration a lot smoother. Something to be said for that... : >-What exactly does caller's $where parameter do? Does it specify a : >starting point for the search? Nope, an ending point, or rather a constraint on the ending point. : No, it specifies what kind of things to look at: : : caller Block; # what block was this block called from? : caller Sub; # what subroutine was this called from? : caller &foo; # what &foo invocation was this called from? : caller Method|Multi # what (multi)method was this called from? : : On reflection, maybe $where isn't the ideal name. Maybe $type, or $kind : would be better? I specifically avoided "type" or "kind" because I didn't want to imply mere type matching when something more general might be happening, such as smart matching, of which type matching is a small subset. Larry
