On 04/11/02 17:52 -0800, [EMAIL PROTECTED] wrote:
> [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]
Mutt?
I'm using mutt and I still haven't had the privledge of correctly viewing one
of these unicode characters yet. I'm gonna be really mad if you say you're
also using an OS X terminal. I suspect that it's my horrific OS X termcap
that's misbehaving here.
Aargh!
Brian
>
> 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 I @y I @z -> $x I $y I $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 P (U+2225 PARALLEL TO). But let's keep it
> out of the signature, I think. In other words, if something like
>
> for @x P @y P @z -> $x, $y, $z { ... }
>
> is to work, then
>
> @result = @x P @y P @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 P 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
