[Note to all: yes, this is me, despite the weirdities of the quoting
and headers. This is how it looks when I using mutt out of the box,
because I haven't yet customized it like I have pine. But I do like
being able to see my own Unicode characters, not to mention everyone
else's. If you don't believe this is me, well, I'll just tell you that
I live on a tropical island near Antarctica, my social security number
is 987-65-4321, and my mother's maiden name was the same as my maternal
grandfather's maiden name. Or something like that... --Ed]
On Mon, Nov 04, 2002 at 02:25:08PM -0800, Michael Lazzaro wrote:
> On Monday, November 4, 2002, at 11:58 AM, Larry Wall wrote:
> >You know, separate streams in a for loop are not going to be that
> >common in practic, so maybe we should look around a little harder for
> >a supercomma that isn't a semicolon. Now *that* would be a big step
> >in reducing ambiguity...
>
> Or more than one type of supercomma, e.g:
>
> for @x ∫ @y ∫ @z -> $x ∫ $y ∫ $z { ... }
>
> to mean:
> for @x ; @y ; @z -> $x ; $y ; $z { ... }
That almost works visually.
> - vs -
>
> for @x § @y § @z -> $x § $y § $z { ... }
>
> to mean:
>
> for @x -> $x {
> for @y -> $y {
> for @z -> $z {
> ...
> }
> }
> }
>
> ;-)
Glad you put the smiley. I think the latter is much clearer.
But at the moment I'm thinking there's something wrong about any
approach that requires a special character on the signature side.
I'm starting to think that all the convolving should be specified
on the left. So in this:
for parallel(@x, @y, @z) -> $x, $y, $z { ... }
the signature specifies that we are expecting 3 scalars to the sub,
and conveys no information as to whether they are generated in parallel
or serially. That's entirely specified on the left. The natural
processing of lists says that serial is specified like this:
for @a, @b, @c -> $x, $y, $z { ... }
Of course, parallel() is a rotten thing to have to say unless you're
into readability. So we could still have some kind of parallizing
supercomma, mabye even ∥ (U+2225 PARALLEL TO). But let's keep it
out of the signature, I think. In other words, if something like
for @x ∥ @y ∥ @z -> $x, $y, $z { ... }
is to work, then
@result = @x ∥ @y ∥ @z;
has to interleave @x, @y, and @z. It's not special to the C<for>.
In the case of C<for>, of course, the compiler should feel free to
optimize out the actual construction of an interleaved array.
I suppose it could be argued that ∥ is really spelled »,« or some such.
However,
@result = @x »,« @y »,« @z;
just doesn't read quite as well for some reason. A slightly better
case could be made for
@result = @x `|| @y `|| @z;
The reason we originally munged with the signature was so that we
could do weird things with differing numbers of streams on the left
and the right. But if you really want a way to take 3 from @x, then
3 from @y, then 3 from @z, there should be something equivalent to:
for round_robin_by_3s(@x, @y, @z) -> $x, $y, $z { ... }
Fooling around with signature syntax for that rare case is not worth it.
This way, the C<for> won't have to know anything about the signature other
than that it expects 3 scalar arguments. And Simon will be happ(y|ier)
that we've removed an exception.
Ed, er, Larry
