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

No Int defaulting in closure capture #139

Open
jfecher opened this issue Oct 8, 2022 · 0 comments
Open

No Int defaulting in closure capture #139

jfecher opened this issue Oct 8, 2022 · 0 comments
Labels
panic A panic within the compiler

Comments

@jfecher
Copy link
Owner

jfecher commented Oct 8, 2022

The code

n = 0
f () =
    g x = print x
    g n

fails with:

b.an:4:5        error: 15 matching impls found for Print a
    g n

/.../ante/stdlib/prelude.an:356:1        note: Candidate 1
impl Print u8  with printne x = print_unsigned (cast x)

/.../ante/stdlib/prelude.an:357:1        note: Candidate 2
impl Print u16 with printne x = print_unsigned (cast x)

/.../ante/stdlib/prelude.an:358:1        note: Candidate 3 (12 more hidden)
impl Print u32 with printne x = print_unsigned (cast x)

The Print a constraint arising from n: a given Int a to be solved at the scope of main - after the Print a constraint is tried so there is no defaulting to i32 yet. There are a few options here:

  • Default to i32 earlier (when?)
  • Delay the solving of Print a, this is the most attractive / seemingly correct option. Looking at the desugared form of the program without closures it is clear the closure environment can be generalized within the lambda:
n = 0
closure = n, fn env -> 
    g x = print x
    g env

env, f = closure
f env
  • Some midground, ad-hoc solution. E.g. When an error involves a defaulting type variable, keep some metadata to default it then and there to see if the error goes away. Any later uses of the variable would appear as i32.
  • Prompt the user for 'type annotations needed by this point' or similar. This could also be confusing, given f is in the process of typechecking we would likely issue this error for f, but it is n that needs a concrete type.
@jfecher jfecher added the panic A panic within the compiler label Oct 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
panic A panic within the compiler
Projects
None yet
Development

No branches or pull requests

1 participant