Hi,
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).
Cheers,
Moritz
