[mercury-users] Another Mercury Modes Problem

[Michael Day]

> At least some of us think the `_skel' convention was a bad idea.  It may
> change when we write version 2 of the library...

Or it may change when someone submits a patch looking like this:

:- inst list(I) ---> [] ; [I|list(I)].
:- inst list_skel(I) == list(I).

Incidentally, on the topic of future standard libraries and insts...

:- typeclass sequence(S, T) S >> T where
	[
		pred next(T, S, S),
		mode next(out, in, out) is semidet
	].

This definition to get the next item from a sequence is obviously
insufficient, as the item may have a non-ground inst.

:- mode next(out(I), in(I), out(I)) is semidet.

This is obviously no good, as the inst of the item may not be the same as 
the inst of the collection, although it might work for the case of unique 
items and collections.

:- mode next(out(I), in(C(I)), out(C(I))) is semidet.

Perfect! Now I can be the inst of the items and C can be the inst
constructor of the collection, eg. list/list_skel of recent debate.

Can we support inst constructor classes in this way? Presumably they will
need some kind of constraints, to work with type classes.

:- typeclass sequence(S, T, C) S >> T, S >> C where
	[
		pred next(T, S, S),
		mode next(out(I), in(C(I)), out(C(I))) is semidet
	].

:- instance sequence(list(T), T, list_skel).

Some of the mode declarations could get pretty hairy, but it would be nice
to have collections that can store unique values and higher order terms.

(Without the mode system, we'd all be using Haskell after all...)

Michael

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------