[m-dev.] Foreign type compare and unification

Peter Schachte schachte at cs.mu.OZ.AU
Tue May 14 14:30:28 AEST 2002


On Tue, May 14, 2002 at 01:32:05PM +1000, Fergus Henderson wrote:
> > I think you really need to let users define these predicates any way
> > they like.
> 
> I agree with you, and that's precisely why I think that It would be nicer
> to devise a solution that doesn't single out unification and comparison
> as the only predicates which users can define any way they like, but
> to instead devise a solution that would work equally well for hashing,
> printing, etc.

Oh, Sorry, I thought you were advocating having users define one or
two predicates for their type (eg, functor/3 and arg/3), and having
Mercury define printing, hashing, etc, in terms of them.  Nevermind.

Actually, it's the "etc." in your message that is the most
interesting.  Are you suggesting that the language designers should
come up with a list of operations that should be defined by default
for all types, but users would be permitted to override the default?
Or are you suggesting that users should be able to define operations
that could be applied to any type, but still permit other users to
define specialized versions of those operations for some of their
types?  The latter would be nicer.  I think this amounts to a special
kind of type class of which every type (at least every algebraic type)
is implicitly an instance, provided that all methods have default
implementations.

-- 
Peter Schachte              In any great organization it is far, far safer
schachte at cs.mu.OZ.AU        to be wrong with the majority than to be right
www.cs.mu.oz.au/~schachte/  alone.
Phone: +61 3 8344 9166          -- John Kenneth Galbraith 
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list