Instances for data types

[Simon Peyton-Jones]

Haskell's inability to hide instance declarations is an oft-discussed
problem.  The designers of the language went to some trouble to arrange
that equality on (say) URIs could not mean one thing in one place and
another thing in another.  Lacking that, it matters exactly where in the
program the type inference engine resolves the overloading, something
that in principle the Haskell type system leaves open.

In short, the implicit-ness of instances conflicts in both practical
ways (e.g. what do you call them), and theoretical ways, with the desire
to localise them.  Implicit parameters were developed largely in
response to this difficulty; they make instances explicit.

My advice would be: use explicit function inside libraries, if you don't
want to expose the functions to the library client.


Your second suggestion, a more elaborate scheme for default methods, has
less by way of theoretical difficulties, I think, though I have never
seen the details worked out.  As usual, there's the question of whether
the benefit in expressiveness is worth the cost in language complexity.
And it makes it harder to answer the question "what code is executed by
this call to foo", because I have to look down
the chain of overlapping instance declarations -- if I can find them. 

Nevertheless, it may be that the practical utility is so great (at least
for some programs) that it'd be worth working out the details.

Simon

| -----Original Message-----
| From: libraries-bounces at haskell.org
[mailto:libraries-bounces at haskell.org] On Behalf Of S. Alexander
| Jacobson
| Sent: 30 April 2004 20:09
| To: Simon Marlow
| Cc: libraries
| Subject: RE: Instances for data types
| 
| Alternatively, since you can't control the export
| of instance declarations, is there a way to
| declare a deriving separate from the definition of
| a type?
| 
| 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
| 
| And (going slightly OT) as long we are are
| simplifying instance declarations, how about
| making it easier to specialize them?  For example
| in my DBMS code, I had stuff like this:
| 
|    instance Property BasicProp String
| 	where
| 	emptyProp x = bpEmpty
| 	deleteRecordId = bpDeleteRecordId
| 	insertRecordId = bpInsertRecordId
| 
|    instance Property BasicProp Integer
| 	where
| 	emptyProp x = bpEmpty
| 	deleteRecordId = bpDeleteRecordId
| 	insertRecordId = bpInsertRecordId
| 
|    instance Property BasicProp Double
| 	where
| 	emptyProp x = bpEmpty
| 	deleteRecordId = bpDeleteRecordId
| 	insertRecordId = bpInsertRecordId
| 
| The actually list of functions is actually much
| longer.  For some types, I may want to specialize
| some of these functions, but for most of them, the
| default behavior is good enough.  I'd like to
| declare default implementations e.g.
| 
|    instance Property BasicProp a where
| 
| And then only if I have a more interesting type
| do:
| 
|    instance Property BasicProp CoolType where
| 
| And only define the functions that are different
| from the default behavior for (Propry BasicProp a)
| 
| -Alex-
| 
| _________________________________________________________________
| S. Alexander Jacobson                  mailto:me at alexjacobson.com
| tel:917-770-6565                       http://alexjacobson.com
| 
| 
| On Fri, 30 Apr 2004, Simon Marlow wrote:
| 
| > On 27 April 2004 20:58, Sven Panne wrote:
| >
| > > Playing around with System.Posix.Terminal, I realized that there
are
| > > no Read, Show, Eq, Enum, ... instances for the data types defined
| > > there (TerminalState, TerminalMode, ...). This is not a very
| > > difficult problem to solve in one's
| > > own program, but it's not very handy, either.
| >
| > By all means go ahead and add these instances.
| >
| > > This raises a general
| > > question: What instances should be defined in the standard
libraries
| > > for types like
| > > this? A general policy would be a good thing. IMHO, at least Read,
| > > Show, Typeable and Eq could be expected, having Ord, Enum and
| > > Bounded, too, would be nice.
| >
| > Good point.  I've been meaning to create a separate document so we
have
| > somewhere to collect general library policies like this.  It's on my
| > whiteboard...
| >
| > Cheers,
| > 	Simon
| > _______________________________________________
| > Libraries mailing list
| > Libraries at haskell.org
| > http://www.haskell.org/mailman/listinfo/libraries
| >
| 
| _______________________________________________
| Libraries mailing list
| Libraries at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries