You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TypeChecker currently does typechecking in two main phases: unification (figuring out the strictes sub-type that works for all of the types in smth like e.g. list) and then weakening (figuring out if certain type can be "weakened" / coerced into a second (expected) type.
If an error happens during unification, we currently don't know in our implementation what is the expected type so we don't report that. We could do know it, it just not implemented that way.
If we wanted, we could refactor this piece of code so that information actually becomes available, probably by making phases of unification and weakening more interwined.
NOTE: If sum types (#381) get implemented, this probably won't be a concern any more, since there will likely be no more unification errors.
The text was updated successfully, but these errors were encountered:
TypeChecker currently does typechecking in two main phases: unification (figuring out the strictes sub-type that works for all of the types in smth like e.g. list) and then weakening (figuring out if certain type can be "weakened" / coerced into a second (expected) type.
If an error happens during unification, we currently don't know in our implementation what is the expected type so we don't report that. We could do know it, it just not implemented that way.
If we wanted, we could refactor this piece of code so that information actually becomes available, probably by making phases of unification and weakening more interwined.
NOTE: If sum types (#381) get implemented, this probably won't be a concern any more, since there will likely be no more unification errors.
The text was updated successfully, but these errors were encountered: