A6: Quick questions as I work on Perl6::Parameters

[Brent Dax]

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. 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. :^) )

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?

-What exactly does caller's $where parameter do? Does it specify a
starting point for the search?

--Brent Dax <bren...@cpan.org>
Unofficial Perl 6 backporter :^)

>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism

[Damian Conway]

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. 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 ;-)

> 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.

> -What exactly does caller's $where parameter do? Does it specify a
> starting point for the search?

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?

Damian

[Simon Cozens]

si...@simon-cozens.org (Simon Cozens) writes:
> Seriously, someone on IRC the other day was claiming that they already
> had a P6RE-in-P5 implementation, and did show me some code, but I've
> forgotten where it lives or their real name.

ttp://www.liacs.nl/~mavduin/P6P5_0.00_01.tar.gz

--
IBM:
It may be slow, but it's hard to use.

[Simon Cozens]

dam...@conway.org (Damian Conway) writes:
> Just wait till you see P::RD's successor: Perl6::Rules ;-)

I was waiting for its successor, Parse::FastDescent. ;)

Seriously, someone on IRC the other day was claiming that they already
had a P6RE-in-P5 implementation, and did show me some code, but I've
forgotten where it lives or their real name.

--
Did you know that 1 barn yard atmosphere = 9.2e-17 erg?

[Damian Conway]

Simon Cozens wrote:
> si...@simon-cozens.org (Simon Cozens) writes:
>
>>Seriously, someone on IRC the other day was claiming that they already
>>had a P6RE-in-P5 implementation, and did show me some code, but I've
>>forgotten where it lives or their real name.
>
>
> ttp://www.liacs.nl/~mavduin/P6P5_0.00_01.tar.gz

Thanks for the pointer. I'm taking a very different approach, but it will
certainly be useful to have two independent and parallel implementations to
run against each other.

Damian

[Simon Cozens]

dam...@conway.org (Damian Conway) writes:
> Thanks for the pointer. I'm taking a very different approach, but it
> will certainly be useful to have two independent and parallel
> implementations to run against each other.

Well, I'll try and dig out the one I wrote at STL too, if regexes haven't
changed too much since then. :)

--
"On a normal ascii line, the only safe condition to detect is a 'BREAK'
- everything else having been assigned functions by Gnu EMACS."
(By Tarl Neustaedter)

[Larry Wall]

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

[Damian Conway]

Larry wrote:

> : 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...

Isn't that still going to break most translations? I mean, if a Perl 5
method (that's being translated to Perl 6) refers to $_, it surely means
$CALLER::_, not $OUTER::_. So Perl 6 calls to it (typically from a different
file scope) won't provide the expected $_ anyway.

> 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.

So maybe $which would be better???

Damian

[Larry Wall]

On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:
: >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.
:
: So maybe $which would be better???

Dunno. That's a bike shed compared to the fact that I'm regretting
bifurcating return into return/leave because of the loss of context
on the args to leave. I've been wondering idly whether we might have
a generic "where" modifier of some sort:

return @foo where Block;
want Lazy where Method;
caller where .label eq "MAINLOOP";
type Int where not $_ % 2

But it's not entirely clear whether there's a general constraint
mechanism lurking in there somewhere. I need to think about that
when I'm smarter, or when someone else is smarter.

Larry

[Damian Conway]

Alternatively, this might be an ideal spot for adverbs:

return :Block @foo;
want :Method Lazy;
caller :{.label eq 'MAINLOOP"};

Or maybe C<where> is just the way we spell the adverb specifier?

Or just use methods:

Block.return(@foo);
Method.want(Lazy);
Whence({.label eq 'MAINLOOP"}).caller;

which, of course, can also look like:

return Block: @foo;
want Method: Lazy;
caller Whence({.label eq 'MAINLOOP"}:;

Damian

[Luke Palmer]

Damian wrote:
> Alternatively, this might be an ideal spot for adverbs:
>
> return :Block @foo;
> want :Method Lazy;
> caller :{.label eq 'MAINLOOP"};

Errr.... what is that odd and disturbing notation? I don't recall
ever seeing that.

> [...]

> return Block: @foo;
> want Method: Lazy;
> caller Whence({.label eq 'MAINLOOP"}:;

Yeah, that's more like it.

Luke

[Damian Conway]

> Or maybe C<where> is just the way we spell the adverb specifier?

And therefore, in turn, perhaps C<where> is how we set properties on a
subroutine call:

foo('bar') where error('fatal');

Then, within the subroutine call, one can access them via C<&_.props>:

sub foo($arg) {
return 1 if $arg eq 'bar'
given &_.props{error} {
when 'fatal' { die "horribly" }
when 'verbose' { warn "direly"; continue; }
default { return 0 }
}
}

This would argue that such adverbs ought usually be specified like properties:

return @foo where from(Block);
want Lazy where context(Method);
caller where context({.label eq 'MAINLOOP"});

which seems to read better anyway.

Damian

[Damian Conway]

Luke Palmer wrote:

>> return :Block @foo;
>> want :Method Lazy;
>> caller :{.label eq 'MAINLOOP"};
>
> Errr.... what is that odd and disturbing notation? I don't recall
> ever seeing that.

Perhaps not. Larry has long been hoarding the colon. One of the possible uses
for it was as an introducer for "adverbs". That is, for non-argument modifiers
on a subroutine call. This was the proposed syntax.

But see my subsequent post on using C<where> in this role instead.

Damian

[Larry Wall]

On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:

: Larry wrote:
: > 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...
:
: Isn't that still going to break most translations? I mean, if a Perl 5
: method (that's being translated to Perl 6) refers to $_, it surely means
: $CALLER::_, not $OUTER::_. So Perl 6 calls to it (typically from a
: different file scope) won't provide the expected $_ anyway.

Most of the people treating $_ dynamically are doing it with subs
and not methods, I suspect. That's where the policy is aimed.
The methods and such would only get caught up in the splash of a
general "sigless doesn't topicalize" rule. You ask for everything
in @_, you're totally on your own, basically, just like in Perl 5.
(Except for the implied "is constant".)

Interestingly, there's no way to explicitly declare that you want the
invocant included in the slurpy array. Maybe this could be forced
to grok it?

method (*@_:)

But that's pretty lame. It doesn't seem all that important to me
to support a way to declare this (other than leaving the sig out
entirely).

Larry

[Damian Conway]

Larry Wall wrote:
> On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:
> : Larry wrote:
> : > 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...
> :
> : Isn't that still going to break most translations? I mean, if a Perl 5
> : method (that's being translated to Perl 6) refers to $_, it surely means
> : $CALLER::_, not $OUTER::_. So Perl 6 calls to it (typically from a
> : different file scope) won't provide the expected $_ anyway.
>
> Most of the people treating $_ dynamically are doing it with subs
> and not methods, I suspect. That's where the policy is aimed.

I must be missing something here. I still don't see how this can work.
I mean, if I write:

module Foo;

sub foo1 {
print "foo1: [$_]\n";
}

sub foo2 is exported {
print "foo1: [$_]\n";
}

__END__

Then, if I'm understanding correctly, those two $_ within the subs
would not be lexically scoped to the subs, but would be the implicit
filescoped $_.

But that doesn't seem to help when I later use that module in another file:

use Foo;

given 'bar' {
foo1(); # prints: foo1=[]
Foo::foo2(); # prints: foo2=[]
}

and get two nasty "undefined value in string interpolation" warnings as well. :-(

Damian

[Nicholas Clark]

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. 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 ;-)

You're just trying to pre-bias all the sucks-o-meters...

( eg
http://home.earthlink.net/~mrob/pub/lang_srom.html
http://www.lehigh.edu/~sol0/rules.html
)

Nicholas Clark

[Matthijs Van Duin]

On Tue, Mar 18, 2003 at 11:36:13PM +0000, Simon Cozens wrote:
>> Seriously, someone on IRC the other day was claiming that they already
>> had a P6RE-in-P5 implementation, and did show me some code, but I've
>> forgotten where it lives or their real name.
>

>http://www.liacs.nl/~mavduin/P6P5_0.00_01.tar.gz

That someone would be me :-)

I should note that this version has wrong semantics: it is incapable of
doing backtracking in various cases including subrules. It only does
backtracking within subexpressions that only does "simple" regex (because
I translate that to a single perl 5 regex match)

My attempt at getting its semantics right is what triggered all my recent
backtracking-related posts. (since continuations are unavailable, it looks
like I'll have to settle for the callback system)

--
Matthijs van Duin -- May the Forth be with you!

[Chromatic]

On Tue, 18 Mar 2003 20:43:00 +0000, Luke Palmer wrote:

> Damian wrote:

>> caller :{.label eq 'MAINLOOP"};

> Errr.... what is that odd and disturbing notation? I don't recall ever seeing
> that.

It's vaguely sinister. Must be the moustache operator.

-- c