Re: Look-ahead arguments in for loops
Miroslav Silovic wrote:
> [EMAIL PROTECTED] wrote:
>
>> And that was never quite resolved. The biggest itch was with
>> operators that have no identity, and operators whose codomain is not
>> the same as the domain (like <, which takes numbers but returns
>> bools).
>>
>> Anyway, that syntax was
>>
>>$sum = [+] @items;
>>
>> And the more general form was:
>>
>>$sum = reduce { $^a + $^b } @items;
>>
>> Yes, it is called reduce, because "foldl" is a miserable name.
>>
>>
>>
>
> To pick some nits, reduce and fold are different concepts. By
> definition, reduce doesn't take the initial value, while fold does.
>
> So reduce using fold is something like
>
>@items || die "horribly";
>foldl &fn, @items[0], @items[1..]
>
> ... while fold using reduce is:
>
>reduce &fn, ($initial, @items)
>
> I think both are useful, depending on the circumstances.
>
>
>Miro
>
Something like:
sub *reduce(&func, +$initial = undef, [EMAIL PROTECTED])
{
$value = $initial;
map { $value = &func($value, $_); } <== @list;
return $value;
}
?
Or would this be an array method? I can see wanting to reduce list
literals, in some wierd mostly-tutorial cases, but I can also see
wanting this to be a data structure method to prevent reducing a parse
tree using an array operation...
=Austin
Re: Look-ahead arguments in for loops
[EMAIL PROTECTED] wrote:
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like <, which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because "foldl" is a miserable name.
To pick some nits, reduce and fold are different concepts. By
definition, reduce doesn't take the initial value, while fold does.
So reduce using fold is something like
@items || die "horribly";
foldl &fn, @items[0], @items[1..]
... while fold using reduce is:
reduce &fn, ($initial, @items)
I think both are useful, depending on the circumstances.
Miro
Re: Look-ahead arguments in for loops
On Sat, Oct 01, 2005 at 02:22:01PM -0600, Luke Palmer wrote:
> And the more general form was:
>
> $sum = reduce { $^a + $^b } @items;
>
> Yes, it is called reduce, because "foldl" is a miserable name.
So, the target of running a loop with both the current
and previous elements accessible could be written as either:
reduce :identity undef
{ code using $^prev and $^cur ... ; $^cur }
@items;
or:
reduce :identity @items[0]
{ code using $^prev and $^cur ... ; $^cur }
@items[1...];
--
Re: Look-ahead arguments in for loops
Austin Hastings wrote: 1. Requirement to repeat the possibly complex expression for the list. 2. Possible high cost of generating the list. 3. Possible unique nature of the list. The subroutine addresses #1, but not 2 or 3. It does address 2. The list is generated once (wherever) and only passed to the subroutine once. No regeneration required. It's exactly like your "all but illegible" solution, just factored out and deuglified. Since I don't understand what you mean by 3, I can't really judge whether it addresses it. But I *can* say it addresses it exactly as well as your "all but illegible" solution did. Also, there's a #4: modified state, which is hinted at but not really covered by #3. 4 is not possible using the pointy sub syntax in any form, since all params to pointy subs are always constant aliases. Damian
Re: Look-ahead arguments in for loops
Damian Conway wrote:
> Austin Hastings wrote:
>
>> All of these have the same solution:
>>
>> @list = ...
>> for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] -> $last, $curr,
>> $next {
>> ...
>> }
>>
>> Which is all but illegible.
>
>
> Oh, no! You mean I might have to write a...subroutine!??
>
Austin Hastings wrote:
>>1. Requirement to repeat the possibly complex expression for the list.
>>2. Possible high cost of generating the list.
>>3. Possible unique nature of the list.
>>
The subroutine addresses #1, but not 2 or 3.
Also, there's a #4: modified state, which is hinted at but not really
covered by #3.
=Austin
Re: Look-ahead arguments in for loops
On 10/1/05, John Macdonald <[EMAIL PROTECTED]> wrote:
> I forget what the final choice was for syntax for the reduce
> operator (it was probably even a different name from reduce -
> that's the APL name), but it would be given a list and an
> operator and run as:
>
> my $running = op.identity;
> $running = $running op $_ for @list;
>
> So, to get a loop body that knows the previous value, you
> define an operator whose identity is the initial value of the
> list and reduce the rest of the list.
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like <, which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because "foldl" is a miserable name.
Luke
Re: Look-ahead arguments in for loops
On Fri, Sep 30, 2005 at 08:39:58PM -0600, Luke Palmer wrote: > Incidentally, the undef problem just vanishes here (being replaced by > another problem). Which reminds me that this same issue came up a while ago in a different guise. There was a long discussion about the reduce functionality that takes an array and applies an operator to each value and the previously collected result. (Much of the discussion was on determining what the identity value for an operator was to initialize the "previous result".) Most of the time that you want a loop that remembers the "previous" value, it can be equally well expressed an a reduction of the series of value using an customer defined operator. I forget what the final choice was for syntax for the reduce operator (it was probably even a different name from reduce - that's the APL name), but it would be given a list and an operator and run as: my $running = op.identity; $running = $running op $_ for @list; So, to get a loop body that knows the previous value, you define an operator whose identity is the initial value of the list and reduce the rest of the list. --
RE: Look-ahead arguments in for loops
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 01, 2005 8:53 AM
> To: perl6-language@perl.org
> Subject: Re: Look-ahead arguments in for loops
>
> Austin Hastings wrote:
>
> > All of these have the same solution:
> >
> > @list = ...
> > for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] -> $last,
> > $curr,
> > $next {
> > ...
> > }
> >
> > Which is all but illegible.
>
> Oh, no! You mean I might have to write a...subroutine!??
>
> sub contextual (@list) {
> return [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef]
> }
>
> for contextual( create_list_here() ) -> $last, $curr, $next {
> ...
This looks useful enough to be in the core, but it needs a couple of
parameters, one to say how many copies of the list it zips up, and another
to say what the first offset is.
sub contextual($number_of_copies, $first_offset, @list) {...} # I'm not
sure how to write it.
Then your example would be
for contextual(3, -1, create_list_here() )-> $last, $first, $next {
Joe Gottman
Re: Look-ahead arguments in for loops
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] -> $last, $curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
sub contextual (@list) {
return [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef]
}
for contextual( create_list_here() ) -> $last, $curr, $next {
...
}
The horror!!!
;-)
Damian
Re: Look-ahead arguments in for loops
Damian Conway wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
>
> for @list ¥ @list[1...] -> $curr, $next {
> ...
> }
>
> ???
1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Possible unique nature of the list.
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] -> $last, $curr,
$next {
...
}
Which is all but illegible.
=Austin
Re: Look-ahead arguments in for loops
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
There's nothing particularly wrong with it -- just as ther's nothing
particularly wrong with any number of other "we don't need this, because
we can program it" things. Perl5 had many other these: "we don't need a
switch statement", "we don't need function signatures", etc.
My original idea, not consuming optional bindings, is barely a new
feature: just a clarification of the rules in a corner-case of the
language. Others took the idea and ran with it and added the bells as
whistles. I guess the best alternative is to say that optional bindings
aren't allowed in this context -- that leaves the issue open for Perl
6.1 (or a module).
Re: Look-ahead arguments in for loops
Mark A. Biggar wrote:
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}
As I remember it zip hrows away extras, not fills in with undef.
Drat I did that backwaeds didn't I.
try:
for @list ¥ [EMAIL PROTECTED], undef] -> $curr. $next {
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Look-ahead arguments in for loops
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}
As I remember it zip hrows away extras, not fills in with undef.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Look-ahead arguments in for loops
On 9/30/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
>
> for @list ¥ @list[1...] -> $curr, $next {
> ...
> }
>
> ???
Thanks. I missed that one.
However, I think your point is pretty much the same as mine.
Certainly adding this to specialized syntax in signature matching is
an overfeature, so I tried to squish it down into options, which we
can add at will without really complexifying the core language. But
without options, like this, is even better.
Incidentally, the undef problem just vanishes here (being replaced by
another problem). Since zip takes the shorter of its argument lists,
you'll never even execute the case where $next is undef.
Luke
Re: Look-ahead arguments in for loops
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Re: Look-ahead arguments in for loops
Austin~
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> >Austin~
> >
> >On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Plus it's hard to talk about backwards. If you say
> >>
> >>for @l -> ?$prev, $curr, ?$next {...}
> >>
> >>what happens when you have two items in the list? I think we're best off
> >>using signature rules: optional stuff comes last.
> >>
> >>
> >
> >I disagree, I think that is an easy call
> >
> >for (1, 2) -> ?$prev, $cur, ?$next {
> > say "$prev -> $cur" if $prev;
> > say $cur;
> > say "$cur -> $next" if $next;
> > say "next";
> >}
> >
> >should print
> >
> >1
> >1 -> 2
> >next
> >1 -> 2
> >2
> >next
> >
> >
> >
> Did you mean:
>
> next
> 1 -> 2 # two spaces
>
> there?
No, my logic is that the loop is run through twice, once with (undef,
1, 2) and once with (1, 2, undef).
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Maybe it's Just Nothing (was: Look-ahead arguments in for loops)
On Thu, Sep 29, 2005 at 11:21:20PM -0600, Luke Palmer wrote:
[ discussion on undefs elided ]
Since we can annotate our undefs now, perhaps undefs that would be
generated because there are no previous or next elements get "tagged"
as such. Something like:
# assuming $b and $a are "before" and "after" elements
for @list -> ?$b, $c, $?a {
given $b {
when undef but generated { say "a fake undef!"; }
when undef { say "a real undef!"; }
}
}
> Oh, right, and as for my favorite actual usage of for:
>
> for @list, :lookbehind(2) :lookahead(1)
> -> $behind1, $behind2, $value, $ahead {
> ...
> }
Hmm. Something like:
for @list -> $c :behind($b1,$b2) :ahead($a1) { ... }
would seem to make a more direct connection between the variables and
what they are aliased to (if only there wasn't that use/mention problem
with the variables).
I think there needs to be something that clearly and unambiguously says
that C<$c> is the value being iterated over and clearly makes a
correspondence between the other variables and their position relative
to C<$c> even with whatever other syntactic mumbling may be necessary.
(And maybe the proposed use of ? is it, but it feels wrong to me)
But, don't we have something like
for @list.kv -> $i,$x { ... }
and even if I'm misremembering @Larry's blessing on that particular
construct, we certainly have this:
for zip([EMAIL PROTECTED](),@list) -> $i,$x { ... }
And then getting the values fore and aft of the current value is just a
matter of indexing into @list. This seems clearer to me than virtual
parameters that exist on either side of the sliding window of the "real"
parameters.
Also, since for seems to be some kind of non-consumptive iterator, maybe
we can get at it with some magical $?ITERATOR variable if we need to:
for @list -> $x {
my ($b1,$b2) = $?ITERATOR.prev(2);
my ($a) = $?ITERATOR.next;# defaults to next(1)
}
Though that's far more syntax than using zip, but has the advantage
that it would work when @list really is a list rather than an array.
I still like using zip() or .kv and indexing the array directly. Putting
the values in an Array-like thingy seems to be a smallish price to pay
for easily getting at some number of elements before or after the
current element.
Rambling in a pre-caffienated way,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Maybe it's Just Nothing (was: Look-ahead arguments in for loops)
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
> >
> >for (1, 2) -> ?$prev, $cur, ?$next {
> > say "$prev -> $cur" if $prev;
> > say $cur;
> > say "$cur -> $next" if $next;
> > say "next";
> >}
> >
> [...]
>
> I assume so because it's the only execution path that seems to work. But
> that would be assuming there was always at least one non-optional
> binding. Given that Luke's against all-optional signatures, too, I'll
> withdraw that part of the suggestion. And with at least one required
> binding, then there's no reason that we can't have the window extend on
> both sides of the current value.
>
> Luke?
Hm, I'm being called upon now.
Well, then I start to ask questions like:
for 1..10 -> ?$a, $b, ?$c, $d, ?$e {...}
Which simply doesn't make any sense to me. Also, figuring out such
things (as is the case with lookbehind argumentS) needs a little bit
too much knowledge about the signature of the function you're viewing.
So instead of sticking that in the signature, we could do it with
adverbs on for:
for 1..10, :lookbehind(1) :lookahead(1) -> $cur, ?$left, ?$right {
...
}
You'll note that, unfortunately, the lookbehind has to come *after*
the cur argument because it must be optional. Hmm... actually, that
doesn't work, because at the beginning of the list you won't have a
$left, and at the end you won't have a $right.
It's possible that it's time to start kicking undef into gear. Until
now in Perl culture, undef has been just a little bit special, with
people not fearing to put it in lists and data structures. There may
be benefit in making it more special, so that people shouldn't define
their own meaning for it. Making exceptions undefs are a step in that
direction. If we take another step in that exact same direction, we
could make undefs exceptions (the converse of before):
sub foo() {
return undef;# almost the exact same as "fail"
}
That is, under "use fatal", all undef return values are converted into
exceptions.
That was somewhat beside the point, but not really. If undefs are a
bit taboo--for example, actually writing "undef" in most code is
considered bad style--then we can steal them for the language's
purposes, such as passing to a for block as lookbehind and lookahead
parameters when you're near the beginning or end of a list.
It seems like I'm making a pretty big deal out of just passing undef
when there is no look-behind/-ahead, but I really want to be able to
distinguish between "there was an undef in the list" and "we're almost
done, so there was actually nothing here". Of course, I still don't
get to distinguish those, but a list with an undef in it becomes much
less common.
The way we can help ease the pain of undef not being available for
user purposes anymore is to allow easy manipulation of Either types.
If you define "easy" weakly, then union types give us that:
union Maybe[::t] (Nothing, Just(::t));
Mmm, Haskellicious. But of course you wouldn't need to declare your
types everywhere because of Perl's dynamic typing/type inference
(depending on your mood). Nothing is nice, but I wouldn't call
working with Just "easy" for Joe Schmoe. It's nice and safe, but it's
annoying sometimes. What I might think I want is:
union Maybe[::t] (Nothing, ::t); # not legal union syntax
You lose a lot with that, though. For instance, Just(Nothing) becomes
unrepresentable. And consequently, nested calls to things that return
Maybes become woosy. So that's not a good idea.
So allowing the definition of Maybe is a good start. But it's
difficult to know whether Perl programmers will put up with it. It's
easier--lazier--just to use undef.
Maybe we ought to call the whole thing off. Undefs have no stigma,
and everything is as usual. If you want to iterate over a list with
lookahead and lookbehind, you shouldn't have put undefs in your list.
The last thing to do, if we want to keep the undef status quo, is to
define Maybe in the language and use it for things like for's
lookahead binding. It's kind of like a "formal undef", something like
"listen, it's pretty common that I won't give you a value here, so I'm
going to mark it specially when I both do and do not". Again, not
easy enough; too much abstraction to think about for an everyday task.
I think my favorite so far is the previous paragraph's resolution.
Just because it's my favorite doesn't mean I'm happy with it.
Oh, right, and as for my favorite actual usage of for:
for @list, :lookbehind(2) :lookahead(1)
-> $behind1, $behind2, $value, $ahead {
...
}
Luke
Re: Look-ahead arguments in for loops
Matt Fowles wrote:
>Austin~
>
>On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
>
>
>>Plus it's hard to talk about backwards. If you say
>>
>>for @l -> ?$prev, $curr, ?$next {...}
>>
>>what happens when you have two items in the list? I think we're best off
>>using signature rules: optional stuff comes last.
>>
>>
>
>I disagree, I think that is an easy call
>
>for (1, 2) -> ?$prev, $cur, ?$next {
> say "$prev -> $cur" if $prev;
> say $cur;
> say "$cur -> $next" if $next;
> say "next";
>}
>
>should print
>
>1
>1 -> 2
>next
>1 -> 2
>2
>next
>
>
>
Did you mean:
next
1 -> 2 # two spaces
there?
I assume so because it's the only execution path that seems to work. But
that would be assuming there was always at least one non-optional
binding. Given that Luke's against all-optional signatures, too, I'll
withdraw that part of the suggestion. And with at least one required
binding, then there's no reason that we can't have the window extend on
both sides of the current value.
Luke?
=Austin
>Matt
>--
>"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
>-Stan Kelly-Bootle, The Devil's DP Dictionary
>
>
>
Re: Look-ahead arguments in for loops
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> >>This is an interesting idea. Perhaps "for" (and "map") shift the
> >>minimum arity of the block from the given list and bind the maximum
> >>arity. Of course, the minimum arity has to be >= 1 lest an infinite
> >>loop occur.
> Or not. We've already seen idioms like
>>
> for (;;) ...
>
> If you specify your minimum arity as 0, then you're obviously planning to
> deal with it. This presumes that iterators can handle behind-the-scenes
> updating, of course.
Well, I see two reasons for not allowing arity zero. First, I think
it's too easy to come up with a function with minimum arity zero:
my @lengths = @list.map:&length # oops, infinite loop
Second, you don't get anything by doing this:
for @list -> [EMAIL PROTECTED] {
...
}
As it's equivalent to:
loop {
...
}
Where you use @list instead of @items.
Luke
Re: Look-ahead arguments in for loops
Austin~
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Plus it's hard to talk about backwards. If you say
>
> for @l -> ?$prev, $curr, ?$next {...}
>
> what happens when you have two items in the list? I think we're best off
> using signature rules: optional stuff comes last.
I disagree, I think that is an easy call
for (1, 2) -> ?$prev, $cur, ?$next {
say "$prev -> $cur" if $prev;
say $cur;
say "$cur -> $next" if $next;
say "next";
}
should print
1
1 -> 2
next
1 -> 2
2
next
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Look-ahead arguments in for loops
Luke Palmer wrote:
>>On 9/29/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
>
>
for grep {defined} @in -> $item, ?$next {
print $item unless defined $next && $item eq $next;
}
>>
>>
>
>>This is an interesting idea. Perhaps "for" (and "map") shift the
>>minimum arity of the block from the given list and bind the maximum
>>arity. Of course, the minimum arity has to be >= 1 lest an infinite
>>loop occur.
>
>
Or not. We've already seen idioms like
for (;;) ...
If you specify your minimum arity as 0, then you're obviously planning to deal
with it. This presumes that iterators can handle behind-the-scenes updating, of
course.
>>But then perhaps you have another way to avoid integer
>>indices:
>>
>>for @list -> $this, [EMAIL PROTECTED] {
>>...
>>}
>>
>>As long as you don't look backwards. Looking backwards makes problems
>>for GC in lazy contexts, so this might just be perfect.
>
Plus it's hard to talk about backwards. If you say
for @l -> ?$prev, $curr, ?$next {...}
what happens when you have two items in the list? I think we're best off using
signature rules: optional stuff comes last.
=Austin
Re: Look-ahead arguments in for loops
On 9/29/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
>for grep {defined} @in -> $item, ?$next {
> print $item unless defined $next && $item eq $next;
>}
This is an interesting idea. Perhaps "for" (and "map") shift the
minimum arity of the block from the given list and bind the maximum
arity. Of course, the minimum arity has to be >= 1 lest an infinite
loop occur. But then perhaps you have another way to avoid integer
indices:
for @list -> $this, [EMAIL PROTECTED] {
...
}
As long as you don't look backwards. Looking backwards makes problems
for GC in lazy contexts, so this might just be perfect.
Luke
Re: Look-ahead arguments in for loops
Dave Whipp wrote:
> Imagine you're writing an implementation of the unix "uniq" function:
>
>my $prev;
>for grep {defined} @in -> $x {
>print $x unless defined $prev && $x eq $prev;
>$prev = $x;
>}
>
> This feels clumsy. $prev seems to get in the way of what I'm trying to
> say. Could we imbue optional binding with the semantics of not being
> consumed?
>
> for grep {defined} @in -> $item, ?$next {
> print $item unless defined $next && $item eq $next;
> }
>
> The same behavior, but without the variable outside the loop scope.
>
>
> It would also be good not to overload the meaning of $?next to also
> tell us if we're at the end of the loop. In addition to FIRST{} and
> LAST{} blocks, could we have some implicit lexicals:
>
> for @in -> $item, ?$next {
> print $item if $?LAST || $item ne $next
> }
>
I like the idea. There's no reason the view window and the consumption
have to be the same.
=Austin
Look-ahead arguments in for loops
Imagine you're writing an implementation of the unix "uniq" function:
my $prev;
for grep {defined} @in -> $x {
print $x unless defined $prev && $x eq $prev;
$prev = $x;
}
This feels clumsy. $prev seems to get in the way of what I'm trying to
say. Could we imbue optional binding with the semantics of not being
consumed?
for grep {defined} @in -> $item, ?$next {
print $item unless defined $next && $item eq $next;
}
The same behavior, but without the variable outside the loop scope.
It would also be good not to overload the meaning of $?next to also tell
us if we're at the end of the loop. In addition to FIRST{} and LAST{}
blocks, could we have some implicit lexicals:
for @in -> $item, ?$next {
print $item if $?LAST || $item ne $next
}
