[mercury-users] Mercury Modes Problem

Mark Brown dougl at cs.mu.OZ.AU
Sat May 25 06:30:47 AEST 2002


On 24-May-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> 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
> 

I forgot to mention an important step.  The second mode above can't work,
because attaching the fitness is no longer a case of binding a term
further.  Instead we replace a no/0 with a yes/1, creating a new term.
So any predicates which attach the fitness to an individual will need two
arguments where previously there was one -- one for the initial term
and one for the new term.  More importantly, any data structures
containing an individual that is updated will themselves need to be
updated.

Perhaps you consider this to be a "killer" for your application?  I hope
not.  Personally, I would recommend programming in this style rather
than use partially instantiated data structures, even though this may
make your code more verbose and probably less efficient, at least in the
short term.  I'd do this for essentially the same reason that I'd
discourage the use of difference lists in languages that support them.

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



More information about the users mailing list