Instances for data types

[Andre Pang]

On 04/05/2004, at 6:39 PM, Simon Peyton-Jones wrote:

> | For example, Network.URI should not have an
> | Eq instance because some applications may
> | legitimately want to define URI equivalence
> | differently (e.g. case sensitivity).  OTOH, there
> | are lots of times when the default behavior is
> | just fine and having to define readsPrec/showsPrec
> | manually is just a PITA.
> |
> | If there isn't already a way to do this
> | how about this strawman syntax:
> |
> |    instance Eq URI default

(Sorry, this message should be in reply to Alex Jacobson's post, but I 
jumped in on the discussion late and don't have the original message to 
reply to).

There's a paper by Wolfram Kahl and Jan Scheffczyk about "named 
instances" which targets that exact problem:

     <http://www.informatik.uni-bonn.de/~ralf/hw2001/4.html>.

      Although the functional programming language Haskell has a 
powerful type class system, users frequently run into situations where 
they would like to be able to define or adapt instances of type classes 
only after the remainder of a component has been produced. However, 
Haskell's type class system essentially only allows late binding of 
type class constraints on free type variables, and not on uses of type 
class members at variable-free types.  In the current paper we propose 
a language extension that enhances the late binding capabilities of 
Haskell type classes, and provides more flexible means for type class 
instantiation. The latter is achieved via named instances that do not 
participate in automatic context reduction, but can only be used for 
late binding. By combining this capability with the automatic aspects 
of the Haskell type class system, we arrive at an essentially 
conservative extension that greatly improves flexibility of programming 
using type classes and opens up new structuring principles for Haskell 
library design.  We exemplify our extension through the sketch of some 
applications and show how our approach could be used to explain or 
subsume other language features as for example implicit parameters. We 
present a typed lambda-calculus for our extension and provide a working 
prototype type checker on the basis of Mark Jones' ``Typing Haskell in 
Haskell''.

Of course, the changes made to the "Typing Haskell in Haskell" type 
checker would have to be propagated back to GHC (if that's possible).


-- 
% Andre Pang : trust.in.love.to.save