Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.map gets confused by IterationEnd sentinel #4582

Closed
p6rt opened this issue Sep 23, 2015 · 6 comments
Closed

.map gets confused by IterationEnd sentinel #4582

p6rt opened this issue Sep 23, 2015 · 6 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Sep 23, 2015

Migrated from rt.perl.org#126147 (status was 'rejected')

Searchable as RT126147$

@p6rt
Copy link
Author

p6rt commented Sep 23, 2015

From zefram@fysh.org

The .map method iterates through its input in a way that will be
prematurely terminated if the IterationEnd sentinel appears in the list.
Obviously this can adversely affect user code that uses .map directly.
But it also breaks some core code, including .perl and .gist on arrays​:

$ ./perl6 -e 'my @​a = 2,3,4; @​a[1] := IterationEnd; say @​a.elems; say @​a.map({ "wibble" }).elems; say @​a.perl; say @​a.reverse.elems; say @​a.reverse.perl'
3
1
[2]
3
[4]

Similar confusion also arises if the sentinel is ever generated in
.map's output​:

$ ./perl6 -e 'my @​a = 2,3,4; say @​a.elems; say @​a.map({ $_ == 3 ?? IterationEnd !! "wibble" }).elems'
3
1

-zefram

@p6rt
Copy link
Author

p6rt commented Sep 23, 2015

From @lizmat

On 23 Sep 2015, at 23​:06, Zefram (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Zefram
# Please include the string​: [perl #​126147]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126147 >

The .map method iterates through its input in a way that will be
prematurely terminated if the IterationEnd sentinel appears in the list.
Obviously this can adversely affect user code that uses .map directly.
But it also breaks some core code, including .perl and .gist on arrays​:

$ ./perl6 -e 'my @​a = 2,3,4; @​a[1] := IterationEnd; say @​a.elems; say @​a.map({ "wibble" }).elems; say @​a.perl; say @​a.reverse.elems; say @​a.reverse.perl'
3
1
[2]
3
[4]

I think this is really a case of DIHWIDT. The IterationEnd sentinel needs to be public, because module makers will need to be able to make their own Iterators.

Similar confusion also arises if the sentinel is ever generated in
.map's output​:

$ ./perl6 -e 'my @​a = 2,3,4; say @​a.elems; say @​a.map({ $_ == 3 ?? IterationEnd !! "wibble" }).elems’
3
1

This is really equivalent to the use of last in​:

$ ./perl6 -e 'my @​a = 2,3,4; say @​a.elems; say @​a.map({ $_ == 3 ?? (last) !! "wibble" }).elems'
3
1

which is both in perl 5 and perl 6 very acceptable usage.

IMHO, this ticket can be rejected.

@p6rt
Copy link
Author

p6rt commented Sep 23, 2015

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Sep 24, 2015

From zefram@fysh.org

Elizabeth Mattijsen via RT wrote​:

I think this is really a case of DIHWIDT.

What, don't put the IterationEnd sentinel in an array? But it's such
an important value, due to its use in the Iterator API. Of course I
need to be able to store it and pass it around.

This is really equivalent to the use of last in​:
...
which is both in perl 5 and perl 6 very acceptable usage.

One is returning a value (which it could have got from anywhere);
the other is invoking a control operator. There's no equivalence in
construction here, only in the effect.

Perl 5 doesn't have last exit a map per se​: the map itself doesn't count
as a loop for that purpose. I agree, though, that it would be fine if
it had been made so (but it is way too late to change now). That would
then be equivalent to your Perl 6 last formulation. But it's not at all
equivalent to the IterationEnd situation. An equivalent to that in Perl
5 would be if a map expression yielding undef terminated the map.

-zefram

@p6rt
Copy link
Author

p6rt commented Sep 24, 2015

From @jnthn

On Wed Sep 23 14​:14​:07 2015, elizabeth wrote​:

On 23 Sep 2015, at 23​:06, Zefram (via RT) <perl6-bugs-
followup@​perl.org> wrote​:

# New Ticket Created by Zefram
# Please include the string​: [perl #​126147]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126147 >

The .map method iterates through its input in a way that will be
prematurely terminated if the IterationEnd sentinel appears in the
list.
Obviously this can adversely affect user code that uses .map
directly.
But it also breaks some core code, including .perl and .gist on
arrays​:

$ ./perl6 -e 'my @​a = 2,3,4; @​a[1] := IterationEnd; say @​a.elems; say
@​a.map({ "wibble" }).elems; say @​a.perl; say @​a.reverse.elems; say
@​a.reverse.perl'
3
1
[2]
3
[4]

I think this is really a case of DIHWIDT. The IterationEnd sentinel
needs to be public, because module makers will need to be able to make
their own Iterators.

Indeed. If people use it for anything aside from the intended purpose (compare it with =​:= to what comes back from an Iterator method) then on their own head be it. And there's no reasonable use for it other than that.

Similar confusion also arises if the sentinel is ever generated in
.map's output​:

$ ./perl6 -e 'my @​a = 2,3,4; say @​a.elems; say @​a.map({ $_ == 3 ??
IterationEnd !! "wibble" }).elems’
3
1

This is really equivalent to the use of last in​:

$ ./perl6 -e 'my @​a = 2,3,4; say @​a.elems; say @​a.map({ $_ == 3 ??
(last) !! "wibble" }).elems'
3
1

which is both in perl 5 and perl 6 very acceptable usage.

True, but let's not encourage people to write that.

IMHO, this ticket can be rejected.

Yup.

/jnthn

@p6rt p6rt closed this as completed Sep 24, 2015
@p6rt
Copy link
Author

p6rt commented Sep 24, 2015

@jnthn - Status changed from 'open' to 'rejected'

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant