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

Non-deducible sequence ending in a Whatever star fails to give an error in Rakudo #2702

Closed
p6rt opened this issue Apr 5, 2012 · 11 comments
Closed

Comments

@p6rt
Copy link

p6rt commented Apr 5, 2012

Migrated from rt.perl.org#112288 (status was 'resolved')

Searchable as RT112288$

@p6rt
Copy link
Author

p6rt commented Apr 5, 2012

From @masak

<moritz> r​: say 1, 2, 6 ... *
<p6eval> rakudo 4373f0​: OUTPUT«...␤»
<moritz> r​: say 1, 2, 6 ... 10
<p6eval> rakudo 4373f0​: OUTPUT«unable to deduce sequence [...]
<masak> moritz​: what was that first one?
<masak> is this something out of RT?
<moritz> it is
<masak> oh good :) it belongs there :)
<moritz> r​: say ~(1, 2, 6 ... *)[10]
<p6eval> rakudo 4373f0​: OUTPUT«␤»
<moritz> eeks
<moritz> no, that particular thing isn't in RT
* masak submits rakudobug

@p6rt
Copy link
Author

p6rt commented Apr 5, 2012

From @pmichaud

On Thu, Apr 05, 2012 at 01​:46​:53PM -0700, Carl Mäsak wrote​:

<moritz> r​: say ~(1, 2, 6 ... *)[10]
<p6eval> rakudo 4373f0​: OUTPUT«␤»
<moritz> eeks
<moritz> no, that particular thing isn't in RT
* masak submits rakudobug

For the moment, I'm going to argue Rakudo's behavior here as
"correct", or at least consistent with the spec.

The sequence (1, 2, 6 ... *) produces a list with
four elements​: 1, 2, 6, and a Failure object containing
"unable to deduce sequence". This list is then asked for
its tenth element, which is Nil (because it's beyond the end
of the list), which is what is stringified and printed.

Since the Failure object is never used, its associated
exception is never thrown.

I suppose one could argue that a ... * sequence should produce
a non-terminating list of Failure objects; I may see if that
works out.

Along similar lines, the other "mostly eager" forms of trying
to obtain the Failure end up not working because the "... *" part
of the sequence signals "treat as potentially infinite at this
point", which pre-empts the mostly-eagerness.

I agree that in most cases a mostly eager operation on a
infinite list should probably go ahead and reify a few terms
from the sequence first, rather than stopping immediately
(e.g. with '...') upon encountering it. But I haven't found
a good bright-line rule for handling this in the general case,
nor do the Synopses have any good hints about it yet.

Pm

@p6rt
Copy link
Author

p6rt commented Apr 5, 2012

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

@p6rt
Copy link
Author

p6rt commented Apr 6, 2012

From @nwc10

On Thu Apr 05 14​:56​:03 2012, pmichaud wrote​:

On Thu, Apr 05, 2012 at 01​:46​:53PM -0700, Carl Mäsak wrote​:

<moritz> r​: say ~(1, 2, 6 ... *)[10]
<p6eval> rakudo 4373f0​: OUTPUT«␤»
<moritz> eeks
<moritz> no, that particular thing isn't in RT
* masak submits rakudobug

For the moment, I'm going to argue Rakudo's behavior here as
"correct", or at least consistent with the spec.

The sequence (1, 2, 6 ... *) produces a list with
four elements​: 1, 2, 6, and a Failure object containing
"unable to deduce sequence". This list is then asked for
its tenth element, which is Nil (because it's beyond the end
of the list), which is what is stringified and printed.

Since the Failure object is never used, its associated
exception is never thrown.

I'm not sure if I should have been asking this on IRC, or on the
language list instead, but, here goes...

I don't know how things map consistently for the general case, but
from that example as a user I would be surprised and disappointed
that the "unable to deduce sequence" isn't reported at compile
time, as a compile time error. (Independent of the bug as reported,
that element 10 is Nil).

In that, as a programmer I would prefer to be told about errors at
compile time, rather than having to rely on good coverage of my
test suite to spot these errors before code gets into production.
And as no test suite is perfect (and not everywhere has tests),
there's going to be a chance that bad code does get into production,
and goes wrong at the most awkward 2am it can find.

Nicholas Clark

@p6rt
Copy link
Author

p6rt commented Apr 9, 2012

From @pmichaud

On Fri, Apr 06, 2012 at 03​:53​:11AM -0700, Nicholas Clark via RT wrote​:

On Thu Apr 05 14​:56​:03 2012, pmichaud wrote​:

On Thu, Apr 05, 2012 at 01​:46​:53PM -0700, Carl Mäsak wrote​:

<moritz> r​: say ~(1, 2, 6 ... *)[10]

For the moment, I'm going to argue Rakudo's behavior here as
"correct", or at least consistent with the spec.

I don't know how things map consistently for the general case, but
from that example as a user I would be surprised and disappointed
that the "unable to deduce sequence" isn't reported at compile
time, as a compile time error. (Independent of the bug as reported,
that element 10 is Nil).

In that, as a programmer I would prefer to be told about errors at
compile time, rather than having to rely on good coverage of my
test suite to spot these errors before code gets into production.
[...]

I agree compile-time detection of the above would be better.
Detecting the above case at compile time will likely be a
function of constant folding built into the compiler; afaik the exact
mechanism for handling that in Rakudo (and even in Perl 6) hasn't
been completely worked out yet. But even if that's available,
I somewhat wonder about something like​:

  my @​a := (1, 2 ... 10000), 10005, 10020 ... *;
  my @​b := 1, 2 ... 10000, 10005, 10020 ... *;

In the above case, do we expect the compiler to compile-time
reify this complete list beyond the 10020 element to get to
the "unable to deduce sequence" error? What tells the
&infix​:<...> operator "Hey, it's compile time, don't be lazy
and keep generating until you reach _this_ point"?

Anyway, I think we'll be more productive to move the
constant-folding and compile-time detection issues to a
separate thread and/or ticket; for this ticket I'd prefer
to stick to the case where the sequence is being deduced
lazily at runtime and we're accessing elements beyond the
deduction failure.

Thanks!

Pm

@p6rt
Copy link
Author

p6rt commented Apr 9, 2012

From @nwc10

On Mon, Apr 09, 2012 at 03​:16​:52PM -0500, Patrick R. Michaud wrote​:

Anyway, I think we'll be more productive to move the
constant-folding and compile-time detection issues to a
separate thread and/or ticket; for this ticket I'd prefer
to stick to the case where the sequence is being deduced
lazily at runtime and we're accessing elements beyond the
deduction failure.

Agree. Should I open a new ticket for this, or has someone with a clearer
idea of the trade offs already set to it?

Nicholas Clark

@p6rt
Copy link
Author

p6rt commented Dec 17, 2014

From @usev6

Nowadays this fails with a typed exception X​::Sequence​::Deduction

$ ./perl6 -e 'say 1, 2, 6 ... *'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did you really mean '..'?)

$ ./perl6 -e 'say 1, 2, 6 ... 10'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did you really mean '..'?)

$ ./perl6 -e 'say ~(1, 2, 6 ... *)[10]'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did you really mean '..'?)

That looks fine to me. If no one objects I'll add a test for this and close the ticket.

1 similar comment
@p6rt
Copy link
Author

p6rt commented Dec 17, 2014

From @usev6

Nowadays this fails with a typed exception X​::Sequence​::Deduction

$ ./perl6 -e 'say 1, 2, 6 ... *'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did you really mean '..'?)

$ ./perl6 -e 'say 1, 2, 6 ... 10'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did you really mean '..'?)

$ ./perl6 -e 'say ~(1, 2, 6 ... *)[10]'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did you really mean '..'?)

That looks fine to me. If no one objects I'll add a test for this and close the ticket.

@p6rt
Copy link
Author

p6rt commented Jan 1, 2015

From @usev6

On Wed Dec 17 13​:31​:07 2014, bartolin@​gmx.de wrote​:

Nowadays this fails with a typed exception X​::Sequence​::Deduction

$ ./perl6 -e 'say 1, 2, 6 ... *'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did
you really mean '..'?)

$ ./perl6 -e 'say 1, 2, 6 ... 10'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did
you really mean '..'?)

$ ./perl6 -e 'say ~(1, 2, 6 ... *)[10]'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did
you really mean '..'?)

That looks fine to me. If no one objects I'll add a test for this and
close the ticket.

I added two tests to S03-sequence/misc.t with commit Raku/roast@f6f6e0b637

I'm closing this ticket now.

1 similar comment
@p6rt
Copy link
Author

p6rt commented Jan 1, 2015

From @usev6

On Wed Dec 17 13​:31​:07 2014, bartolin@​gmx.de wrote​:

Nowadays this fails with a typed exception X​::Sequence​::Deduction

$ ./perl6 -e 'say 1, 2, 6 ... *'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did
you really mean '..'?)

$ ./perl6 -e 'say 1, 2, 6 ... 10'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did
you really mean '..'?)

$ ./perl6 -e 'say ~(1, 2, 6 ... *)[10]'
===SORRY!===
Unable to deduce arithmetic or geometric sequence from 1,2,6 (or did
you really mean '..'?)

That looks fine to me. If no one objects I'll add a test for this and
close the ticket.

I added two tests to S03-sequence/misc.t with commit Raku/roast@f6f6e0b637

I'm closing this ticket now.

@p6rt
Copy link
Author

p6rt commented Jan 1, 2015

@usev6 - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant