Alternately named arguments

[Luke Palmer]

Presuming you can do:

(who => $name, why => $reason) := (why => $because, who => "me");

(from A6)

Does that imply that you can do:

sub routine (name => $nombre, date => $fecha) {...}

Anyway, I just realized that this is finally an elegant way to do
multiple, unordered return values:

(name => $name, id => $id) := getinfo();

(Or, in this precise case:)

(+$name, +$id) := getinfo();

Luke

[David Storrs]

Just confirming something...if you did this:

($name, $id) := &getinfo();

I think you would end up storing an alias to the getinfo() sub in $name, and
undef in $id. Is that correct?

What would happen if you did this?

(+$name, +$id) := &getinfo();

I would expect a compile time error, because you can't bind a sub
alias to a scalar that is being forced into numeric context.

--Dks

[Luke Palmer]

David Storrs writes:
> On Fri, Oct 24, 2003 at 12:57:18AM -0600, Luke Palmer wrote:
> > Presuming you can do:
> >
> > (who => $name, why => $reason) := (why => $because, who => "me");
> >
> > (from A6)
> >
> > Does that imply that you can do:
> >
> > sub routine (name => $nombre, date => $fecha) {...}
> >
> > Anyway, I just realized that this is finally an elegant way to do
> > multiple, unordered return values:
> >
> > (name => $name, id => $id) := getinfo();
> >
> > (Or, in this precise case:)
> >
> > (+$name, +$id) := getinfo();
>
>
> Just confirming something...if you did this:
>
> ($name, $id) := &getinfo();
>
> I think you would end up storing an alias to the getinfo() sub in $name, and
> undef in $id. Is that correct?

Yeah, providing getinfo has an empty sig.

Well, if we take the binding/parameter passing equivalency a little
farther, that can be an error. Which may turn out to be good:

($name, $id) := getinfo(); # I want getinfo to return 2 values

($name, ?$id) := getinfo(); # I realize that it may only return 1

Etc.

> What would happen if you did this?
>
> (+$name, +$id) := &getinfo();
>
> I would expect a compile time error, because you can't bind a sub
> alias to a scalar that is being forced into numeric context.

Nu...meric context? I meant that as named parameters, that is,
expecting getinfo to return a list of pairs. So I think that will be an
error, just for a different reason.

Luke

[Damian Conway]

Luke Palmer asked:

> Presuming you can do:
>
> (who => $name, why => $reason) := (why => $because, who => "me");
>
> (from A6)
>
> Does that imply that you can do:
>
> sub routine (name => $nombre, date => $fecha) {...}

If we're consistent about lvalues of binds being the same as argument lists,
it probably does.

> Anyway, I just realized that this is finally an elegant way to do
> multiple, unordered return values:
>
> (name => $name, id => $id) := getinfo();

Yep.

> (Or, in this precise case:)
>
> (+$name, +$id) := getinfo();

Err, no. Or at least: "Please, No!". ;-)

That would certainly be a way cool abbreviation, but I suspect it would be a
Very Bad Idea for unary plus to have two unrelated meanings out in the actual
code. I suspect that the "named-only" markers are only available within actual
parameter lists.

Damian

[Luke Palmer]

Hi Damian, welcome back!

Damian Conway writes:
> Luke Palmer asked:
>
> >Presuming you can do:
> >
> > (who => $name, why => $reason) := (why => $because, who => "me");
> >
> >(from A6)
> >
> >Does that imply that you can do:
> >
> > sub routine (name => $nombre, date => $fecha) {...}
>
> If we're consistent about lvalues of binds being the same as argument lists,
> it probably does.

Neat.

>
> >Anyway, I just realized that this is finally an elegant way to do
> >multiple, unordered return values:
> >
> > (name => $name, id => $id) := getinfo();
>
> Yep.
>
>
> >(Or, in this precise case:)
> >
> > (+$name, +$id) := getinfo();
>
> Err, no. Or at least: "Please, No!". ;-)

Good. That made my stomach hurt.

Luke

[David Wheeler]

On Sunday, October 26, 2003, at 05:05 PM, Damian Conway wrote:

> Err, no. Or at least: "Please, No!". ;-)
>
> That would certainly be a way cool abbreviation, but I suspect it
> would be a Very Bad Idea for unary plus to have two unrelated meanings
> out in the actual code. I suspect that the "named-only" markers are
> only available within actual parameter lists.
>
> Damian

Welcome back, Damian. Lo, how we've missed you and Larry these many
long months!

Regards,

David

--
David Wheeler AIM: dwTheory
da...@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: The...@jabber.org
Kineticode. Setting knowledge in motion.[sm]

[Damian Conway]

David Wheeler wrote:

> Welcome back, Damian. Lo, how we've missed you and Larry these many long
> months!

Thanks to everyone for the warm welcome. Just to give you an update, I've be
ill too (nothing nearly as serious as Larry...just a mild influenza and a
little light pneumonia ;-) and I've also been busy attempting to earn a living.

I'm close to a first draft of Exegesis 7 (on formatting), including a module
implementing the full functionality. And then I'm looking forward to working
with Larry and the rest of the Design Team on Apocalypse/Exegesis 12
(Objects), when Larry is well enough to do so.

I've made no further progress on Perl6::Rules, though I did but in a TPF grant
application for a few month's support to let me finish it. I will of course
continue working on the module in any case, but only *very* slowly since it
will have to be shoe-horned between design, module maintenance, and various
income-earning activities.

Meanwhile, we should continue to bear in mind how much *has* already been
achieved. Whilst I was on my most recent speaking tour I had the opportunity
to give several updated versions of my Perl 6 talk (including the marathon
6-hour version). And once again it brought home to me just how far we've come
and how elegant and powerful the result is. We ought to have a:

Perl 6:
Worth waiting for!

t-shirt, because it truly is. :-)

Damian

[Larry Wall]

On Mon, Oct 27, 2003 at 12:05:32PM +1100, Damian Conway wrote:
: Luke Palmer asked:
: >(Or, in this precise case:)

: >
: > (+$name, +$id) := getinfo();
:
: Err, no. Or at least: "Please, No!". ;-)
:
: That would certainly be a way cool abbreviation, but I suspect it would be
: a Very Bad Idea for unary plus to have two unrelated meanings out in the
: actual code. I suspect that the "named-only" markers are only available
: within actual parameter lists.

I don't think there's any ambiguity with it. A C<:=> always forces its
left side to a binding context. At that point in the parse, the left
side tree has to be traversed anyway to reinterpret everything, so the
meaning of the C<+> can be determined subsequent to the initial parse.

That being said, there is probably a style of programming enforced
by a stricture that disallows binding to existing variables, for the
same reason that we disallow binding subroutine parameters to global
variables. In that case, you'd be required to introduce the list
with a C<my>, and so you'd already know you were in a weird context
when parsing. It could be argued that C<:=> implies a C<my>, in fact.
But I still think it's better to require the C<my> for visual reasons,
and to make it easy to search for declarations.

Larry

[Damian Conway]

Larry wrote:

> : > (+$name, +$id) := getinfo();
> :
> : Err, no. Or at least: "Please, No!". ;-)
> :
> : That would certainly be a way cool abbreviation, but I suspect it would be
> : a Very Bad Idea for unary plus to have two unrelated meanings out in the
> : actual code. I suspect that the "named-only" markers are only available
> : within actual parameter lists.
>
> I don't think there's any ambiguity with it.

Nor do I. At least, not to the machine. People may not be as clear on the
distinction, though.

> A C<:=> always forces its
> left side to a binding context. At that point in the parse, the left
> side tree has to be traversed anyway to reinterpret everything, so the
> meaning of the C<+> can be determined subsequent to the initial parse.

Which the machine can do very easily, I agree. People may not be as good as
reinterpreting everything in context. Especially a context thats imposed by a
*trailing* infix operator.

> That being said, there is probably a style of programming enforced
> by a stricture that disallows binding to existing variables, for the
> same reason that we disallow binding subroutine parameters to global
> variables. In that case, you'd be required to introduce the list
> with a C<my>, and so you'd already know you were in a weird context
> when parsing. It could be argued that C<:=> implies a C<my>, in fact.
> But I still think it's better to require the C<my> for visual reasons,
> and to make it easy to search for declarations.

Okay, I wouldn't have nearly as much problem with having two unrelated
meanings for prefix '+' and '?', if the second meaning were always confined
to the declaration lists of C<my>'s and C<subs>. Because (a) we're clearly
prefix-marked as being in a declaration in both those cases, and (b)
declarations are compile-time, so we can simply explain that +, ?, and * have
distinct compile-time and run-time meanings.

But trying to understand the run-time-only variations in what + and ? mean in
this:

($X, +$Y, ?$Z) := ($x, +$y, ?$z);

vs this:

($X, +$Y, ?$Z) = ($x, +$y, ?$z);

is a novice's nightmare. :-(

So can we say that, even if non-declarative bindings *are* allowed, within
them unary + and ? and * always take their run-time meanings (i.e. almost
always an error)?

Damian