Hi,
Erik Meijer proposes that the Haskell type system be replaced by the Gofer
type system. In particular the Gofer type system does not require type
constraints to be of the form C a where C is a class identifier and a is
a type variable. Also maybe somewhat more motivating is the fact that Gofer
allows multiple parameter type class. An example of where context reduction
causes problems might be as follows:
> class Test a where
> test :: a -> a
> instance Test [Char] where
> test x = x
This small example is rejected by the Haskell type system, whereas the Gofer
type system produces the (maybe) expected result. Though this is a simple and
somewhat limited example, I hope it is clear that there exist places where
context reduction can limit the expressiveness of the language (see Simon early
posting for example.)
However, the Gofer type system as so allows unconstrained multiple parameter
type classes, which I believe can lead to problems. There are many motivating
examples where extending Haskell's single relation type classes have proved
useful, not least the examples given by Meijer and Hutton in there encoding
of fold and unfold to exponential types [MH]. There are however many examples
where multiple parameter type classes can lead to ambiguous types, which will
be rejected by the Gofer type system (yes examples that cannot be type checked
by Gofer!) For example, consider the following example taken from the work
of Chen, Hudak and Odersky [CHO]:
> class Sequence a s where
> cons :: a -> s -> s
> nth :: s -> Int -> a
> len :: s -> Int
> instance Sequence a (List a) where
> cons = (:)
> nth = (!)
> len = (#)
Feeding this example into the Gofer type system produces the following error
message:
ERROR "tmp.lhs" (line 4): Ambiguous type signature in class declaration
*** ambiguous type : Sequence a b => b -> Int
*** assigned to : len
I am aware at of least two approaches to solving this problem. The first
is parametric type classes proposed by Chen, Hudak, and Odersky [CHO]. One
of the nice properties about their system is the fact that it is only a
conservative extension of the Haskell type system. The second approach is
to use the notation of improvement described by Jones in his work on
simplifying and improving qualified types [J].
To summarise the main point of this reply is to state that though I am in
agreement with both Simon and Erik, I believe that an extensions or changes to
the current Haskell type system should be conservative. As such, I do not
believe it would be in the interest of Haskell to adopt the Gofer type system.
Many regards,
Ben
[MH]
@inproceedings{meijer95,
author = "Erik Meijer and Graham Hutton",
title = "Bananas in Space: Extending fold and unfold
to Exponential Types",
note = "Proc.\ 7th International Conference on Functional
Programming and Computer Architecture",
publisher = "ACM Press, San Diego, California",
month = jun,
year = 1995}
[CHO]
@inproceedings{chen1992a,
author ="Chen, Juang and Hudak, Paul and Odersky, Martin",
title ="Parametric type classes",
booktitle ="Conference on Lisp and Functional programming",
month ="June",
year ="1992",
documentURL ="ftp://ftp.ira.uka.de/pub/uni-karlsruhe/papers/odersky-lfp92.ps.gz
"
}
[J]
@inproceedings (jones95d,
author = "Mark P. Jones",
title = "Simplifying and Improving Qualified Types",
booktitle = "International Conference on Functional
Programming Languages and Computer Architecture",
year = "1995",
month = "June",
note = "At extended version, with proofs, appears as Research report
YALE/DCS/RR-1040, Yale University, New Haven, Connecticut USA,
June 1994",
pages = "160--169")
--------
Benedict R. Gaster.
Functional Programming Group, Nottingham University.
Category theory: This is how our children will program!
