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

inconsistent whether type constraint violation is compile error #4919

Open
p6rt opened this issue Dec 24, 2015 · 4 comments
Open

inconsistent whether type constraint violation is compile error #4919

p6rt opened this issue Dec 24, 2015 · 4 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Dec 24, 2015

Migrated from rt.perl.org#127014 (status was 'open')

Searchable as RT127014$

@p6rt
Copy link
Author

p6rt commented Dec 24, 2015

From zefram@fysh.org

Is it legal to compile code that, if executed, would always produce
an exception? Rakudo seems conflicted on the matter. Most often it is
permitted, as in these cases​:

sub () { my constant \a := 3.5e0; my Int $b; $b = a if False; }
sub () { #`(Sub|94227680) ... }
sub () { my constant \a := 3.5e0; my Int $b; $b = a; }
sub () { #`(Sub|94218864) ... }

Both of these contain an assignment expression that would produce an
exception if executed. In the latter case, the assignment would be
executed if the subroutine were called. In the former case, it would
not be executed even then. In both cases I have not actually called
the subroutine, so no problem arises at this stage. But if I wish then
I can call them, to get the obvious runtime behaviour​:

(sub () { my constant \a := 3.5e0; my Int $b; $b = a if False; })()
()
(sub () { my constant \a := 3.5e0; my Int $b; $b = a; })()
Type check failed in assignment to $b; expected Int but got Num
  in sub at <unknown file>​:1
  in block <unit> at <unknown file>​:1

However, the following two very similar cases don't permit the code to
be compiled​:

sub () { my Int $b; $b = 3.5e0 if False; }
===SORRY!=== Error while compiling <unknown file>
Cannot assign a literal of type Num (3.5e0) to a variable of type Int. You can declare the variable to be of type Real, or try to coerce the value with 3.5e0.Int or Int(3.5e0), or just write the value as 3
at <unknown file>​:1
------> sub () { my Int $b; $b = ^3.5e0 if False; }
sub () { my Int $b; $b = 3.5e0; }
===SORRY!=== Error while compiling <unknown file>
Cannot assign a literal of type Num (3.5e0) to a variable of type Int. You can declare the variable to be of type Real, or try to coerce the value with 3.5e0.Int or Int(3.5e0), or just write the value as 3
at <unknown file>​:1
------> sub () { my Int $b; $b = ^3.5e0; }

Note that, like the first pair of cases, I'm not attempting to
actually execute the problematic assignment. In both cases the code is
syntactically well-formed, and even meaningful, in that we can say exactly
how it would behave if the subroutine were called, if the compiler had
allowed us to get that far. The behaviour would be identical to that
seen in the second pair of cases.

Making code like this error at compile time impedes the use of the
language with machine-generated code. It is quite normal to end up
generating dead branches that are well-formed but can never be reached,
and because they're unreachable the logic of the generating program may
have little to say about how they would behave if reached. For this
reason and for general predictability (given that one doesn't know how
clever the compiler will be this week) it is unwise to refuse to compile
code just because one can predict that it would fail if executed. If the
compiler spots such a situation, it can make better use of its foresight
by optimising the compilation, directly emitting code to generate the
exception at runtime.

-zefram

@p6rt
Copy link
Author

p6rt commented Dec 24, 2015

From @skids

Making code like this error at compile time impedes the use of the
language with machine-generated code.

This probably bears hashing out on IRC or ML rather than RT (then linking
the discussion back here.)

I suspect the eventual answer will be "maybe we should have a flag
available for such machine-generated code, but human users will want
earlier warnings to find bugs earlier during development and care
less about predictability."

@p6rt
Copy link
Author

p6rt commented Dec 24, 2015

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

@p6rt
Copy link
Author

p6rt commented Dec 24, 2015

From @geekosaur

On Wed, Dec 23, 2015 at 9​:40 PM, Zefram <perl6-bugs-followup@​perl.org>
wrote​:

Is it legal to compile code that, if executed, would always produce
an exception? Rakudo seems conflicted on the matter.

Pretty sure better compile time checking is a known issue and was not
expected or intended to be resolved by the first release; it's an ongoing
evolution.

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant