Alternately named arguments

(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

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

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.

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

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

Yep.

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

Neat.

Good. That made my stomach hurt.

Luke

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]

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

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

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

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.

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