[mercury-users] list functor style functions

[Peter Schachte]

On Fri, Nov 12, 1999 at 02:15:06AM +1100, Michael Day wrote:
> last week people debated creating a typeclass to allow other sequence
> types to emulate the behaviour of lists by letting them be constructed in
> the same way. My question is whether the following definitions are useful:
> 
>         func [] = C(T),
>         mode [] = out is det,
>         mode [] = in is semidet,
> 
>         func [T|C(T)] = C(T),
>         mode [in|in] = out is det,
>         mode [out|out] = in is semidet,

I would suggest putting them into to separate type classes.  There may
be collections you can deconstruct one element at a time but not
construct that way, or vice versa.  Or you may be able to do both, but
not the same way.  Eg, a set: it certainly makes sense to traverse a
set one element at a time (say, in lexicographic order).  It also
makes sense to build up a set one element at a time.  However, these
are not inverses unless you can guarantee that the set will be
constructed in (reverse) order.

Here's a tough question about the current type class implementation
(and about what other languages' type class systems do):  if I define
input_sequence and output_sequence type classes to each have the
approriate (dual) modes of these functions, can I then define sequence
to be just these two classes, *and* have Mercury require that these
two pairs of functions be the identical, but with different modes?
Ie, a sequence type can not only add and remove an element, but these
two operations are forced to be duals because they're just different
modes of the same function?  That would be pretty cool.

> They would appear to me to allow use of any type that satisfies this type
> class in the same way as lists. But I'm wondering if the definitions are
> overly restrictive. For full compatibility with lists, the [] function has
> to be used in two ways, to compare as an empty sequence and to create
> empty sequences. As functions cannot specify different code for different
> modes I'm guessing this will not always be possible, especially
> considering the current standard library has always made the distinction
> between `init' and `is_empty'.

This idiom in the library has always irked me because it discourages
reuse-through-reversibility.

> Is it
> desirable to have functions that work in many modes or separate them?
> .... I understand with the C interface I
> can possibly do that, but should I *want* to do that?

Sure you should; I don't think that should be controversial.  No one
should be surprised if the best algorithm to compute some relation is
different in different modes.  The only controversy should be over
what to do about the possibility that the code you write that you
implicitly assert just computes different modes of the same relation
in fact computes different relations.  I'd argue that the benefit of
this flexibility outweighs the danger, but I can see why some might
disagree.  (Actually, as you point out, this is possible now via the C
interface, it's just very unpleasant and inefficient.  This is another
argument for supporting it directly).

-- 
Peter Schachte                     All truth goes through three stages.
mailto:schachte at cs.mu.OZ.AU        First it is ridiculed. Then it is
http://www.cs.mu.oz.au/~schachte/  violently opposed. Finally, it is
PGP: finger schachte at 128.250.37.3  accepted as self-evident.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------