hask icon indicating copy to clipboard operation
hask copied to clipboard

Correctly unify typeclass constraints when inferring types

Open billpmurphy opened this issue 9 years ago • 2 comments

When a TypeVariable with typeclass constraints are unified with a TypeOperator, the type system (i.e., unify in hindley_milner.py) does not check to see if the TypeOperator is actually a member of the required typeclasses. As a result of this, some TypeErrors related to typeclass membership will not be raised until function-call time (as opposed to function-compose time).

For example, consider show (of the Show typeclass). When show is composed with id, the typeclass constraints will be unified and the composed function will have the correct constrained type. If you compose show with a function with a concrete (TypeVariable) output type which is not a member of Show, the type inference system will not check the constraint and raise a TypeError until the composed function is actually called.

billpmurphy avatar Jul 28 '15 23:07 billpmurphy

The solution might lies in this place since you didn't copy the constraints to the new TypeVariable.

The origin version of this HM type system python implement did not take constraints into acocunt.

tonyfloatersu avatar Sep 14 '18 08:09 tonyfloatersu

BTW you can try to add an option for Arrow in the fresh function since you might encounter the function with sig (int -> int) be copyed into (-> int int), which looks terrible...

Actually not just Arrow entry, you might need to add Tuple and List as well...

p.s. I do appreciate this awesome project, but it seems to be dead for quite a while... I feel sorry about it.

tonyfloatersu avatar Sep 14 '18 09:09 tonyfloatersu