Carlosī got the flue and could not come to work. Iīd like to join
Kevin on his fight :-).
I think system CT is simple and will make the type system and life for
programmers simpler. A language based on system CT would require no
class or instance declarations (although they could be kept for
documentation or checking), so I am not sure about how and if Mark
Jones type checker could be used for making the system available in
Haskell.
So letīs begin fighting...
1) Repeating, overloading with system CT is simpler than with type
classes, especially for programmers. They do not need to figure out
what type to write in class and instance declarations (types are
infered). They will not anymore be concerned about strange
superclasses, strange subclasses and common frustrating unresolved
overloading error messages. Types in system CT are simpler, since, for
specifying a type, the programmer does not need to know the whole
hierarchy of necessary constraints. Programmers will not anymore be
confused about type errors that arise because they forgot to include a
constraint (for example, Eq a).
As another example, discussed recently, the type of "u . map fst",
where "u" is overloaded by bindings "u = union" and "u = unionBy"
would be, in Haskell (well, Hugs)
(Eq a, Functor d, U (d e) a c) => d(e, f)->[a]->c
whereas, in System CT, the *automatically inferred* type would be
{map::((e, f)->e)->d->b, u::b->[a]->c}. d->[a]->c
in a context where map is overloaded for lists and functions:
map::(a->b)->[a]->[b] and
map::(a->b)->(c->a)->(c->b)
In Hugs, the programmer may not just forget about the type above (Hugs
requires it to be specified; I donīt know why).
2) Overloading as in system CT is type safe and statically typed. We
have a semantics and a type soundness proof (to be submitted for
publication soon).
3) The fact that problems are soluble does not mean that a better
solution does not exist. I think that this occurs with respect to
overloading and the use of multiple parameter type classes and
functional dependencies. The burden is on the programmer to figure out
types and their functional dependencies, where type inference and
simple overloading of definitions could be used instead. In my view,
sources of problems lie in 1) context-free instantiation of types by
the Haskell type system, and 2) the definition of ambiguity in the
Haskell type system. All "technical" :-) details to be given in the
upcoming article.
4) I think system CT should not be treated as an extension of Haskell
type classes. With system CT, class and instance declarations are not
needed.
I strongly agree with the view that Haskell has far cleaner syntax
than just about any other language. But I think that the same does not
apply to the treatment of overloading.
Lucilia
