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

Interpreter crash #2053

Closed
athas opened this issue Nov 30, 2023 · 3 comments
Closed

Interpreter crash #2053

athas opened this issue Nov 30, 2023 · 3 comments
Assignees
Labels

Comments

@athas
Copy link
Member

athas commented Nov 30, 2023

def f [n] (reps:[n]i64) : ?[m].[m]i64 =
  iota (reduce (+) 0 reps)

entry main arr = length (f (map (\x -> x) arr))
@athas athas added the bug label Nov 30, 2023
@athas athas self-assigned this Nov 30, 2023
@athas
Copy link
Member Author

athas commented Nov 30, 2023

This is because while map (\x -> x) arr) does end up occurring in a size expression, and has bindings which we do not allow, it is not itself a size - in fact, it is not even scalar. Thus replacing it with an unknown size is not sensible. We should replace the entire size expression where it occurs with an unknown size.

@athas
Copy link
Member Author

athas commented Nov 30, 2023

Another reason this happens is that the return type ascription is ignored for some reason, and this more precise type is inferred:

def f [n] (reps:[n]i64) : [reduce (+) 0 reps]i64 =
  iota (reduce (+) 0 reps)

entry main arr = length (f (map (\x -> x) arr))

@athas
Copy link
Member Author

athas commented Nov 30, 2023

Actually, maybe this is fine, and we just need to change our conception of "unknown size" to "unknown value", and the interpreter shouldn't assume it's an i64. The compiler handles it fine already.

@athas athas closed this as completed in 6fa6254 Nov 30, 2023
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