Instances for data types

[S. Alexander Jacobson]

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
>