Re: very basic type checking
Moritz Lenz wrote: 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). In that case, perhaps Rakudo should have a config or compile-time (of Rakudo itself) option where it can be run either without or with any compile-time optimizations, where said optimizations have any changing the runtime behavior. This being under the assumption that a Rakudo codebase that doesn't support the optimizations is simpler and easier to prove correct or debug than one with them. Users suspecting a bug when they run with the optimizations could rerun without them to see if there's a difference. This idea isn't without precedent. I believe that Parrot has long had multiple run cores, such as ones with JIT or certain optimizations versus ones without. Or maybe this was an early development that later went away? -- Darren Duncan
Re: very basic type checking
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
Re: very basic type checking
yary wrote: Yes but- the OP wasn't asking about my Str $s; my Int $i=$s; not failing at compile time, the question was about my Int $i='abc'; or how about sub square(Int $n='o hai'); Would it be wrong for the "cut-off point" be after an immediate assignment/ declaration of a built-in type to a literal constant? Or does even checking that at compile time lead to headache? You're right, and this *should* be caught at compile time, because it is the low-hanging fruit, and can be tested with little effort. My point is that, because compile-time testing isn't essential, it was probably further down the priority queue of the Rakudo developers. It very much should be done, and relatively soon, but so far it was quite reasonable to have waited. -- Darren Duncan
Re: very basic type checking
On Thu, Jun 24, 2010 at 12:08 AM, Jan Ingvoldstad wrote: > On Wed, Jun 23, 2010 at 20:21, Darren Duncan >wrote: > > > If all invocations of myop use a code literal for the $y argument, then > > this can be checked at compile time, but if the argument is a variable, > they > > have to look further out. > > > > > Yup. > > For those who don't quite see what this leads to, consider the Halting > Problem for why this looking around, out, in, between, sideways, back, and > forward must have cut-off points. > Yes but- the OP wasn't asking about my Str $s; my Int $i=$s; not failing at compile time, the question was about my Int $i='abc'; or how about sub square(Int $n='o hai'); Would it be wrong for the "cut-off point" be after an immediate assignment/ declaration of a built-in type to a literal constant? Or does even checking that at compile time lead to headache?
Re: very basic type checking
On Wed, Jun 23, 2010 at 20:21, Darren Duncan wrote: > If all invocations of myop use a code literal for the $y argument, then > this can be checked at compile time, but if the argument is a variable, they > have to look further out. > > Yup. For those who don't quite see what this leads to, consider the Halting Problem for why this looking around, out, in, between, sideways, back, and forward must have cut-off points. -- Jan
Re: very basic type checking
Hiroki Horiuchi wrote:
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?
Generally speaking, in a dynamic language like Perl 6, one has to do the type
checking at runtime anyway, because we don't always have the information to do
it at compile time and because it is simpler. Runtime checks can always be
local while compile time checks may have to encompass an arbitrarily large
amount of other code that provides context.
Having just runtime checks is sufficient to begin with because they will still
always catch the errors. Compile time checks are then something you can add to
this in some, but not all, cases, and there are various degrees of diminishing
returns, where some compile time tests like the one you gave above would be very
easy to do but others are increasingly difficult.
An example of a problem that is more difficult to check at compile time is:
sub myop (Int $x, Int $y) {
return $x / $y;
}
Assuming that division by zero should be an error, a compile-time check won't
find a problem from just examining that code. Rather, a compile-time check
would have to check all the code that invokes myop, and any code that produces
the value to eventually give to $y, in order to know at compile time if the code
would try to divide by zero.
If all invocations of myop use a code literal for the $y argument, then this can
be checked at compile time, but if the argument is a variable, they have to look
further out.
-- Darren Duncan
