: > (+$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
