[mercury-users] Another Mercury Modes Problem

David Overton dmo at cs.mu.OZ.AU
Sat Jun 1 00:51:53 AEST 2002

jn Fri, May 31, 2002 at 05:03:08PM +0900, Bob McKay wrote:
> I think we're talking at cross purposes here. My overall aim is to
> write a system with at least three levels:
> .a top level, generic evolutionary algorithm
> .a mid level, with interchangeable instantiations of this to a
> 	particular evolutionary algorithm and data structure (eg genetic
> 	algorithm with bitstrings; evolutionary strategy with real
> 	representation; or a strange variant with clauses as the
> 	representation)
> .a bottom level, at which an individual problem - particular
> 	fitness function, representation  details such as dimensions -
> 	is defined.
> So the outer level needs to define not only the required procedures,
> but parametric types and modes for them. They would be instantiated
> in the lower levels to define the actual types and modes. This seems
> straightforward for types, but not possible for modes for the reasons
> I previously mentioned (ie that you can't have parametric unique or
> bound modes). Or am I missing something here?

Parametric modes (i.e. modes containing inst variables) are supported.


:- mode append(in(list_skel(I)), in(list_skel(I)), out(list_skel(I))).

defines a mode for append/3 where the elements of the input lists have
some inst `I' and the elements of the output list also have inst `I' after
the procedure succeeds.

There is an implicit constraint `I =< ground' in this example which says
that `I' is constrained to be a "sub-inst" of `ground'.  This includes
all higher-order insts and bound(...) insts where the arguments are
ground.  If you want `I' to be constrained to be a sub-inst of some other
inst, e.g.  `unique', you need to explicitly say this in the
declaration.  The syntax for this is similar to the syntax for type
class constraints.  E.g.

:- mode append(di(unique_list_skel(I)), di(unique_list_skel(I)),
	out(unique_list_skel(I))) <= I =< unique.

constrains `I' to be a unique inst.

Note that the second of these example only works with fairly recent ROTD
releases (since approx mid March).

David Overton      Computer Science and Software Engineering
PhD Student        The University of Melbourne   +61 3 8344 9159
Research Fellow    Monash University (Clayton)   +61 3 9905 5779
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

More information about the users mailing list