[m-dev.] Foreign type compare and unification

[Ralph Becket]

Mark Brown, Tuesday, 21 May 2002:
> 
> What I'm saying is that the behaviour of the program should not depend on
> a closed world assumption about the members of a typeclass.

This is what will happen anyway with generic predicates that use dynamic
type class casts.

> However, this particular objection is not very hard to overcome.  Consider
> the following motivating example, the intent of which should be clear.
> 
> 	:- typeclass printable(T) where [
> 		func to_doc(T) = doc
> 	].
> 
> It would be nice to provide a generic method implementation, along the
> lines of the function pprint__to_doc in the standard library.  Perhaps
> something like the following (note that, unlike ordinary instance
> declarations, the parameter is a type variable):
> 
> 	:- generic_instance printable(T) where [
> 		(to_doc(X) = pprint__to_doc(X))
> 	].
> 
> This would _not_ imply that all types are members of the typeclass.  In
> order to declare a type to be in the typeclass, we could use an ordinary
> instance declaration, or we could use something like:
> 
> 	:- derived_instance printable(foo).
> 
> This would use the generic method, binding the hidden type parameter to
> the type_info for foo.

Surely this is the same as providing default method implementations?
(Except that your suggestion hints at having to provide a full suite of
default implementations rather than just a subset, which may be more
appropriate or even necessary in some situations.)

> In our example, most types could get by with a derived instance, but types
> which we want to print using special syntax (e.g. lists) would have an
> ordinary instance.  If both an ordinary instance and a derived instance are
> declared, this should be an error.
> 
> It turns out, though, that this proposal doesn't achieve what I hoped it
> might.  I was hoping that it would be possible to write a generic method
> which, like pprint__to_doc, deconstructs terms of any type and makes a
> recursive call for each argument.  While this is fine for pprint__to_doc,
> whose polymorphism is unconstrained, it won't work for our typeclass method
> because the arguments would need to be dynamically cast into the printable
> typeclass before the method can be called.  And there's the rub: if we had
> dynamic typeclass casts, then we could implement this whole example without
> using generic/derived instances at all.

Yep!  And still have the problem you pointed out at the beginning.

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