On Fri, Oct 21, 2005 at 04:04:25PM -0600, Luke Palmer wrote:
: However, if I get my wish of having zip return tuples, then it can be
: left-associative. But since it interleaves instead, making it left-
: or right-associative gives strange, incorrect results.
I expect zip ought to bundle up into tuples of some sort. But then
maybe zip is not what we want for typical loops. I'm thinking that
"for" wants to be a little more incestuous with -> anyway, so that
the optionality of the -> arguments can tell "for" how to deal with
short lists. And now that we have general multidimensional slices,
it'd be nice if "for" were one of the operators that is aware of that.
Then you might be able to say things like:
for (@foo; 1...) -> $val, $i {...}
for @foo <== 1... -> $val, $i {...}
1... ==>
for @foo -> $val, $i {...}
1... ==> #######v
@foo ==> #v v
for () -> $val, $i {...}
all of which should in theory be equivalent, and none of which use "zip".
(With a bit of handwaving about how ==> binds to the list before
a final -> block.)
With a clever enough parser, we even get back to the A4 formulation of
for @foo; 1... -> $val, $i {...}
But that's relying on the notion that a statement can function as a
funny kind of bracketing device that can shield that semicolon from
thinking it's supposed to terminate the statement. That's probably
not too far off from what it does now when it knows it wants a final
block, so that a bare block where an operator is expected pops back
up to the statement level.
I know that, with tuple matching signatures, zip can be made to work
even as a tuple constructor, but it seems like a waste to constuct
tuples only to throw them away immediately. And if we're going to
build surreal lists into the language, we should probably use them.
Larry
