Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
Larry Wall writes:
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.
if I understand correctly, the main problems with Apocalypse version
of for are :
* need for special meaning of ; in the nlock signature
* need to specify unifying/intersection/other behaviour
* not everybody is happy with strean vs block arguments alignment
possibilities
one solution , to which thetread converged (??) is to essentially give
simple ways to weave many streams in single one, and for to become
always single-stream . this is essentially the old a ^| b proposal
written in english. it doesnot solve the alignment problem. also ,
it seems ( but may be I am wrong ) that there is run-time overhead ,
since weaving if done explicitly takes additional time ~ length of
arrays . this will not happen if for will notice one of weaving
functions and optimize it away. So that means that we will have to
have standart set of weaving functions recognizable by for .
so possibly we can revive the multistream for if we wrap this
behaviour around loop and given , something like this
loop {
given each a - $x {
given each b - $y {
given each c - $z {
last loop if undef $x|$y|$z
this is already valid perl6 syntax if array a have iterator method
similar hash. ( may be it is called a.next or a.iter ) .
and if each will notice how many arguments closure expects.
as it is , it looks weird , and we loose the fact that for loop is
*single* topicalizer scope ( here we have to break 3 of them to get
out . and also the topic inside the ... is the *last* argument $z and
not the first as would be for usual for .
so strictly speaking , this is not wrapping around -- this is just
valid (??) sintax. but may be it *is* possible to somehow wrap the
multistream behaviour around loop - given pair.
I dont know. maybe new keyword stream
loop {
stream a - $x,$y {
stream b - $z{
stream c - $alpha,$beta {
last loop if undef $x|$y|$z
and stream does not set the topicilizer scope. it seems that
stream is just a function . and then it does not automatically
create a topicalizer scope.
or maybe each is sort of redundant inside given and we have
loop {
given a - [$x,$y ] {
given b - [$z ] {
given c - [$alpha,$beta] {
last loop if undef $x|$y|$z
but then a will have to remember its current index.
and given to be aware of it. may be its too much for given.
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 Cfor 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.
and for this type of things there is always weaving possibility.
arcadi .
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
On Mon, Nov 04, 2002 at 07:27:56PM -0800, Brian Ingerson wrote: : 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! I'm using mutt version 1.4i. The stock mutt on my RedHat wasn't new enough. Larry
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
On Tue, Nov 05, 2002 at 11:36:45AM -0500, Ken Fox wrote:
: Jonathan Scott Duff wrote:
:
: Um ... could we have a zip functor as well? I think the common case
: will be to pull N elements from each list rather than N from one, M
: from another, etc. So, in the spirit of timtowtdi:
:
: for zip(a,b,c) - $x,$y,$z { ... }
:
: sub zip (\:ref repeat{1,}) {
:my $max = max(map { $_.length } _);
:my $i = 0;
:while ($i $max) {
:for (_) {
:yield $_[$i]
:}
:++$i
:}
:return ( )
: }
:
: That prototype syntax is probably obsolete, but I'm not sure
: what the current proposal is. It might be better to force scalar
: context on the args so that both arrays and array refs can be
: zipped.
You never have to put \ into a signature anymore--that's the default.
You only get list context (and flattening) when you use the splat.
For a recurring scalar context, you want something like:
sub zip (refs is repeatedly (Array)) {
The exact syntax is subject to change, of course.
: I really like the idea of using generic iterators instead of
: special syntax. Sometimes it seems like we're discussing 6.x
: instead of just 6.0.
:
: This iterator is nice too:
:
: sub pairs (\a, \b) {
:my $max = max(a.length, b.length);
:my $i = 0;
:while ($i $max) {
:yield a[$i] = b[$i];
:++$i
:}
:return ( )
: }
:
: for pairs (a, b) {
:print .x, .y
: }
Neither of these work on arrays which have a finite but unknown length.
Larry
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
On Tue, Nov 05, 2002 at 03:21:54PM +1100, Damian Conway wrote:
Larry wrote:
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 Cfor.
Very nice. The n-ary zip operator.
Um ... could we have a zip functor as well? I think the common case
will be to pull N elements from each list rather than N from one, M
from another, etc. So, in the spirit of timtowtdi:
for zip(@a,@b,@c) - $x,$y,$z { ... } # one at a time
for zip(@a,@b,@c,3) - $x,$y,$z { ... } # three at a time
zip() would interleave its array arguments one at a time by
default and N at a time if the last argument is a number. Then the
RHS of the arrow just tells perl (and us) how many things to pull from
the resultant list. This would, of course, lead to strange things
like this though:
for zip(@a,@b,2) - $x,$y,$z { ... }
but perl is always giving us enough rope. Besides ... someone may
want/need those semantics.
Or perhaps just:
sub take(int $n, *@from) {
yield splice @from, 0, $n while @from $n;
return ( @from, undef xx ($n-@from) )
}
three = take.assuming(n=3);
for three(@x), three(@y), three($z) - $x, $y, $z { ... }
Or if we generalized zip() a little:
for weave(@a,2,@b,1) - $x,$y,$z { ... }
Which would take 2 elements from @a, and one from @b, until both
arrays were exhausted.
I'm just casting for alternatives to the punctuative versions in case
I hit something that's really good :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
Jonathan Scott Duff wrote:
Um ... could we have a zip functor as well? I think the common case
will be to pull N elements from each list rather than N from one, M
from another, etc. So, in the spirit of timtowtdi:
for zip(a,b,c) - $x,$y,$z { ... }
sub zip (\:ref repeat{1,}) {
my $max = max(map { $_.length } _);
my $i = 0;
while ($i $max) {
for (_) {
yield $_[$i]
}
++$i
}
return ( )
}
That prototype syntax is probably obsolete, but I'm not sure
what the current proposal is. It might be better to force scalar
context on the args so that both arrays and array refs can be
zipped.
I really like the idea of using generic iterators instead of
special syntax. Sometimes it seems like we're discussing 6.x
instead of just 6.0.
This iterator is nice too:
sub pairs (\a, \b) {
my $max = max(a.length, b.length);
my $i = 0;
while ($i $max) {
yield a[$i] = b[$i];
++$i
}
return ( )
}
for pairs (a, b) {
print .x, .y
}
- Ken
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
Scott Duff wrote:
Very nice. The n-ary zip operator.
Um ... could we have a zip functor as well?
Yes, I expect so. Much as C|, C, and C^ will be operator versions
of Cany, Call, and Cone.
And I'd suggest that it be implemented something like:
sub zip(ARRAY *sources; $by = 1) {
if exists $by all(sources).isa(PAIR) {
warn Useless 'by' argument (every array already has a count);
}
else {
for sources { $_ = $_=$by unless .isa(PAIR) }
}
my zipped;
while any(sources).key {
push zipped, splice(.key, 0, .value) for sources;
}
return zipped;
}
So, in the spirit of timtowtdi:
for zip(a,b,c) - $x,$y,$z { ... } # one at a time
for zip(a,b,c,3) - $x,$y,$z { ... } # three at a time
As implied above, I think the N-at-a-time behaviour would be better
mediated by an optional named parameter. So that second one should be:
for zip(a,b,c,by=3) - $x,$y,$z { ... } # three at a time
Or if we generalized zip() a little:
for weave(a,2,b,1) - $x,$y,$z { ... }
Which would take 2 elements from a, and one from b, until both
arrays were exhausted.
As Buddha Buck suggested elsewhere, and as I have coded above,
I would imagine that this functionality would be mediated by pairs
and merged into a single Czip function. So that last example is just:
for zip(a=2,b=1) - $x,$y,$z { ... }
Damian
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
[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 Cfor.
In the case of Cfor, 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 Cfor 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
RE: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
Larry Wall:
(B# for @x $B!B(B @y $B!B(B @z - $x, $y, $z { ... }
(B
(BEven if you decide to use UTF-8 operators (which I am Officially
(BRecommending Against), *please* don't use this one. This shows up as a
(Bbox in the Outlook UTF-8 font.
(B
(B--Brent Dax [EMAIL PROTECTED]
(B@roles=map {"Parrot $_"} qw(embedding regexen Configure)
(B
(BWire telegraph is a kind of a very, very long cat. You pull his tail in
(BNew York and his head is meowing in Los Angeles. And radio operates
(Bexactly the same way. The only difference is that there is no cat.
(B--Albert Einstein (explaining radio)
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
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 Cfor.
In the case of Cfor, 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 Cfor 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
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
Larry wrote:
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).
I'd rather we not use that. I found it surprisingly hard to
distinguish∥from ||. May I suggest that this might be the opportunity
to deploy ¦ (i.e. Ebrvbar).
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 Cfor.
Very nice. The n-ary zip operator.
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.
Agreed.
A slightly better case could be made for
result = x `|| y `|| z;
Except by those who suffer FIABCB (font-induced apostrophe/backtick
character blindness).
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 { ... }
Or perhaps just:
sub take(int $n, *from) {
yield splice from, 0, $n while from $n;
return ( from, undef xx ($n-from) )
}
three = take.assuming(n=3);
for three(x), three(y), three($z) - $x, $y, $z { ... }
???
Fooling around with signature syntax for that rare case is not worth it.
This way, the Cfor 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.
and reinstituted the previous exception that a semicolon in an parameter
list marks the start of optional parameters! :-)
Damian
Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
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 { ... }
- vs -
for x ¡× y ¡× z - $x ¡× $y ¡× $z { ... }
to mean:
for x - $x {
for y - $y {
for z - $z {
...
}
}
}
;-)
MikeL
