Maybe it's Just Nothing (was: Look-ahead arguments in for loops)
Luke Palmer
> 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
Jonathan Scott Duff
[ 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(0..@list.elems(),@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
du...@pobox.com
Damian Conway
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Mark A. Biggar
Shouldn't that be:
for [@list, undef] ¥ @list[1...] -> $curr, $next {
...
}
As I remember it zip hrows away extras, not fills in with undef.
Luke Palmer
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
Mark A. Biggar
> 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 [@list, 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 ¥ [@list[1...], undef] -> $curr. $next {
Dave Whipp
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).
Austin Hastings
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 ¥ [@list[1...], undef] -> $last, $curr,
$next {
...
}
Which is all but illegible.
=Austin
Damian Conway
> All of these have the same solution:
>
> @list = ...
> for [undef, @list[0...]] ¥ @list ¥ [@list[1...], 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 ¥ [@list[1...], undef]
}
for contextual( create_list_here() ) -> $last, $curr, $next {
...
}
The horror!!!
;-)
Damian
Joe Gottman
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
John Macdonald
> 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.
--
Luke Palmer
> 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
Austin Hastings
> Austin Hastings wrote:
>
>> All of these have the same solution:
>>
>> @list = ...
>> for [undef, @list[0...]] ¥ @list ¥ [@list[1...], 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
Damian Conway
>>>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
John Macdonald
> 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...];
--
Miroslav Silovic
>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
Austin Hastings
Something like:
sub *reduce(&func, +$initial = undef, *@list)
{
$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