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