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
