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

Checking types of constructors defined in Prelude #143

Open
ppolesiuk opened this issue Aug 28, 2024 · 0 comments
Open

Checking types of constructors defined in Prelude #143

ppolesiuk opened this issue Aug 28, 2024 · 0 comments
Labels
error messages Improving error messages provided to the programmer proposal New ideas that should be discussed, but not necessarily implemented

Comments

@ppolesiuk
Copy link
Member

Some constructors are defined in Prelude, but used by some transformations (see TypeInference.PreludeTypes). Currently, the implementation doesn't check their types: it assumes that they are defined as usual. In extremely rare cases, these assumptions are not correct, which leads to "Internal type error" message, like in the following code:

data Option X = None | Some

let foo {?x} = x

let _ = foo {x=42}

I'm not sure if this is a right design. Handling such cases correctly would require some complicated code, just to report an error that should be never seen by the casual programmer. The "Internal type error" in such rare cases seems to be good enough. On the other hand, I treat internal type errors as a tool for developers: when they occur, something is really bad in the DBL implementation. Assuming that our implementation is correct, the user should be not able to see such an error.

@ppolesiuk ppolesiuk added proposal New ideas that should be discussed, but not necessarily implemented error messages Improving error messages provided to the programmer labels Aug 28, 2024
@ppolesiuk ppolesiuk mentioned this issue Jan 13, 2025
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error messages Improving error messages provided to the programmer proposal New ideas that should be discussed, but not necessarily implemented
Projects
None yet
Development

No branches or pull requests

1 participant