[mercury-users] Mercury Modes Problem

[Mark Brown]

On 24-May-2002, Bob McKay <bob_mckay at mac.com> wrote:
> On Friday, May 24, 2002, at 02:13 PM, Mark Brown wrote:
> >>Does this mean what it seems to - that I can't take in a partially
> >>instantiated data structure, instantiate it further, and pass it
> >>out?
> >
> >Yes, that is correct in our current implementation.
> >
> 
> Aaaarggh, that may be the killer for my application. The obvious
> way to handle a population of individuals in evolutionary systems
> is to have the individual created as a structure containing the
> definition of the individual, with the fitness uninstantiated, then
> to later instantiate the fitness as it is evaluated (in general, the
> fitness may depend on other individuals in the population, so it
> can't just be added at generation time). With this restriction, I'll
> need to keep (at least) two separate parallel data structures. Is the
> restriction likely to be removed anytime in the foreseeable future?

The bad news is that the restriction is not likely to be removed in the
foreseeable future.

The good news is that the restriction is generally not that hard to
overcome.  Say your type was as follows:

	:- type individual
		--->	individual(
				definition,
				fitness
			).

and you would like to use an intermediate inst somewhere between free
and ground, where the first argument is ground but the second is free.
This inst can be expressed as:

	:- inst init_individual == bound(individual(ground, free)).

and you would make use of the three modes:

	free >> init_individual		% to create the individual
	init_individual >> ground	% to bind the fitness
	in				% to use the individual

but, as you observed, this isn't supported by our implementation.

You can instead encode the "freeness" of the fitness in the type, rather
than the inst, using maybe/1 from the standard library as follows:

	:- type individual
		--->	individual(
				definition,
				maybe(fitness)
			).

Then you could express the intermediate inst without using partially
instantiated data:

	:- inst init_individual == bound(individual(ground, bound(no))).

The main drawback is that a 'ground' individual would no longer mean the
same thing, so you wouldn't be able to use modes 'in' or 'out', for
example, without lots of switches on the maybe type appearing throughout
your code.  Instead, you could define your own final inst:

	:- inst individual == bound(individual(ground, bound(yes(ground)))).

and you would make use of the three modes:

	free >> init_individual		% to create the individual
	init_individual >> individual	% to bind the fitness
	in(individual)			% to use the individual

On a final note, this style of programming will be easier when we
implement our subtyping proposal (search the developers mailing list
archive for "subtyping proposal").  This _is_ something we hope to
implement in the foreseeable future.

Cheers,
Mark.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------