2 ms·
> If we're talking about high-level abstractions, this is probably not the best way to describe Haskell. (In fact, Haskell's type system is notoriously ad hoc,
by Peaker 15y ago
> If we're talking about high-level abstractions, this is probably not the best way to describe Haskell. (In fact, Haskell's type system is notoriously ad hoc, compared to languages like ML.)
In what sense is Haskell's type system any more ad-hoc than ML's?
They're almost equivalent, except for Haskell's type-class extension, which is used for ad-hoc polymorphism. Support for ad-hoc polymorphism does not make the type system ad-hoc. It means you can use (\*) for multiplication between any type of number, which is very useful.
Many GHC extensions to the type systems are also based on sound theory (Rank 2/N types, Type families, GADTs) and not ad-hoc. ML lacks these too.
Haskell is one of the forefronts of applied type theory, AFAIK, ML seems to stagnate in this area.
- ekidd 15y agoIn what sense is Haskell's type system any more ad-hoc than ML's? According to Mark P Jones, the author of "Typing Haskell in Haskell": Haskell benefits from a sophisticated type system, but implementors, programmers, and researchers suffer because it has no formal description. http://web.cecs.pdx.edu/~mpj/thih/ http://web.cecs.pdx.edu/~mpj/thih/ Haskell's type system was designed to make programming delightful. I vastly prefer it to some of the contortions of ML's type system, such as the separate + and +. operators. But by functional programming standards, I think that any type system without an official description can be fairly described as ad hoc.