[m-dev.] modes in typeclass instances

David Overton dmo at cs.mu.OZ.AU
Wed Oct 11 16:05:46 AEDT 2000


On Wed, Oct 11, 2000 at 02:17:21PM +1100, Thomas Charles CONWAY wrote:
> Hi
> 
> I was just considering a SAX (xml serialization interface) typeclass.
> Here is an abstracted bit of the typeclass:
> 
> :- typeclass documentHandler(Handler) where [
>     (pred startElement(string, list(pair(string)), Handler, Handler)),
>     (mode startElement(in, in, SomeKindOfIn, SomeKindOfOut) is det)
> ].
> 
> Now, depending on what concrete type Handler takes, I might want different
> input and output modes.
> 
> In some instances "in" and "out" might be sufficient.
> In others it might be desirable to use "di" and "uo" (if the Handler
> is the io__state, for example). Or you might want something in between
> (such as when the io__state is stored in a structure which is a Handler).

Well, you can do `mode startElement(in, in, di, out)' and this will
work fine with either (in, out) or (di, uo) or anything in between,
but I suspect it probably doesn't do what you want (e.g. you don't
want to lose the uniqueness of your io__state).

> 
> Now, if the typeclass requires that the mode be "di", an
> instance that uses "in" is legal in as much as any use of the arguments
> by the caller will satisfy the mode constraints of the callee.
> Unfortunately the same is not true of the "uo" argument, since the
> caller is expecting the argument variable to be unique, when in fact
> it is shared. This looks like a place that polymorphic ground modes
> would be useful, but it needs to be trickier than anything I've seen
> so far. You need the inst parameter to be a typeclass parameter or
> something.

I have thought about adding inst parameters to typeclasses.  It would
also be useful for instances that require higher-order insts.
However, I haven't yet worked out how to parameterise uniqueness.  In
my current implementation of polymorphic ground insts the mode checker
still needs to know the uniqueness of each ground inst variable (if it
doesn't know, it assumes it is shared).

> 
> Suggestions? Comments?


David
-- 
David Overton      Department of Computer Science & Software Engineering
PhD Student        The University of Melbourne, Victoria 3010, Australia
+61 3 8344 9159    http://www.cs.mu.oz.au/~dmo
--------------------------------------------------------------------------
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