Instances for data types

[S. Alexander Jacobson]

Hmm.  The feature in this paper looks really
useful!  Right now I am working on log
writing/recovery code and running into the
difficulty/annoyance of wanting to override the
read/show methods for CalendarTime provided by the
Time library.  I don't want to have to write my
own Read/Show for all the various intervening
types that eventually contains CalendarTime!
(Note: Based on my cursory read, I don't think I
can use implicit parameters to solve this problem
so if there is a choice between one or the other,
I prefer named instances!)

I'm not sure, but it also looks like names
instances may give you the ability to declare Set
as an instance of Monad.  Yay! (apropos a prior
thread).

I can't tell whether it allows me to do the type
defaulting that would have been useful for the
DBMS code, but if it did, even better!

Another nice thing about named instances is that
it gets rid of the annoying lack of globality of
instance declarations.  For some reason it is ok
to do:

  import MyModule (hiding myFunc)
  import MyModule2 (myFunc)

But you can't do the same with instance
declarations.  Note: I don't know if this means
that myFunc means different things in different
places, but I don't see why instance declarations
should be treated differently.


-Alex-

_________________________________________________________________
S. Alexander Jacobson                  mailto:me at alexjacobson.com
tel:917-770-6565                       http://alexjacobson.com


On Tue, 4 May 2004, Andre Pang wrote:

> 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
>