search

billpmurphy / hask

Haskell language features and standard libraries in pure Python.
BSD 2-Clause "Simplified" License
860 stars 33 forks source link

Correctly unify typeclass constraints when inferring types #1

Open billpmurphy opened 9 years ago

billpmurphy commented 9 years ago

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.

tonyfloatersu commented 6 years ago

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 commented 6 years ago

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.