[m-rev.] diff: unique modes for list__reverse
Michael Day
mikeday at bigpond.net.au
Wed Oct 24 17:15:41 AEST 2001
> It's possible to abstract over certain properties of insts, e.g. subtype
> information. But completely abstract insts are pretty useless, since
> there's almost nothing you can do with them (e.g. because the inst
> in question might be `dead').
Doesn't the same objection apply to abstract types? If you have a variable
of type queue(T) and inst queue(I) for some given T and I, you can pass it
to a predicate that is expecting a value of that type and inst.
If public insts cannot refer to the functors of abstract types (as they
presumably cannot) then we need abstract insts to implement container
types that can hold stuff with interesting insts:
:- type queue(T).
:- inst queue(I).
:- pred queue__put(queue(T), T, queue(T)).
:- mode queue__put(in(queue(I)), in(I), out(queue(I))) is det.
...
:- implementation.
:- type queue(T) == pair(list(T)).
:- inst queue(I) == bound(pair(list_skel(I), list_skel(I))).
so in fact, it looks like I'm asking for abstract equivalence insts. And
while I'm at it, it would be nice to have a list(I) inst rather than
list_skel, especially as the inst declaration is identical to the type
declaration:
:- inst list(I)
---> []
; [I|list(I)].
Michael
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list