On Thursday, October 31, 2002, at 10:03 PM, John Siracusa wrote:
The current syntax offers a significant advantage, though. I'm assuming parser knows to look for equal numbers of things on both sides of the ->. If we go with the proposed alternate syntax, won't we run into the problem where it sees:On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:Damian Conway writes:BTW, Both Larry and I do understand the appeal of interleaving sources and iterators. We did consider it at some length back in January, when we spent a week thrashing this syntax out.Of course, I can't speak for Larry, but in the end I concluded that interleaving iterator variables is a false win, since it trades reduced syntactic complexity for increased semantic complexity, but only really improves the readability of a comparatively rare case.but why ? I am just curious about details.Yeah, I'd like to hear those details too, because the alternate syntax:sure looks a lot more attractive and sensible to me, and I agree with all1) for @a -> $x ; @b -> $y { ... }
the arguments in favor of it so far. In particular:
* No "look here, then look there" connection between (possibly) widely
separated items.
* Simple to add or remove/comment-out individual stream/item(s) pairs
without having to "count" what are essentially positional parameters to make
sure you haven't mis-mapped anything in the process.
* More familiar use of the semicolon (IMO)
for @a -> $a; as a complete postfix for loop that just happens to do nothing?
I suppose the same could be said for the existing syntax. "for @a;" would look like a loop with the default topic variable. Maybe I'm just wrong, but the proposed syntax seems to introduce ambiguity by breaking the for loop up a bit too much, while the current use of the "->" and semicolons holds the whole thing together.
As for maintaining the sanctity of the semicolon, I would offer that consistency of the arrow operator is more important.