Am 23.06.2010 13:59, schrieb Hiroki Horiuchi:
I asked the same question to #perl6.
But now I think it was a wrong place.

no, you had the bad luck of asking at a time when nobody was around.

My question is:
In current Rakudo,
my Int $i = '123';
causes a runtime error, not a compile time error.
How about in future Perl 6?

In general this is a very hard problem. Let me explain why.

Perl 6 is a very extensible language; you can override built-in functions, methods and operators, as well as add new multi variants.
So in a seemingly simple case as

my Str $x = 2 + 3

the compiler has to know
1) which infix:<=> and infix:<+> multis are available in the current lexical scope 2) if those are pure functions that can be executed at compile time without loss of semantics 3) about local grammar modifications that might change the meaning of the number literals
4) if there is a local redefiniton of the Str type

Since the + is implemented as a multi sub, it can't just know the return type, but it has to execute the 2 + 3 at compile time (constant folding) to find the type of the return value.

That is why the specification doesn't mandate a minimum level of type inference at compile time.

That said, the consensus seems to be that detecting failures early (ie at compile time) is a good thing, as far as it's robust.

Back to the current situation, I don't think we will significant effort on constant folding, type checking or other things at compile time prior to the Rakudo Star release.

Tyler Curtis is currently working on an optimization framework (sponsored by Google as part of the "Summer of Code" project), which I plan to use to play around with compile-time transformations.

But I fear that optimizations are a risky business, considering our rather low test coverage (and considering that we don't really know how much of our code paths are actually covered by tests).


Reply via email to