[mercury-users] Another Mercury Modes Problem

[Bob McKay]

On Friday, May 31, 2002, at 04:19 PM, Ralph Becket wrote:

> Bob McKay, Friday, 31 May 2002:
>>
>
> Garbage is any data that is not reachable - that is, via a pointer on
> the stack or a live local variable.  Garbage is collected and the space
> is reused.
>
> Glad to have cleared that one up.

So just to ensure that I understand this clearly (since I don't know
about the innards of the compiler, I'm not certain what is reachable,
because I don't know for sure how the stack is implemented): space is
eligible for garbage collection as soon as there is no call forward
of that point that refers to it (or is this true only in determinate
contexts?)

>
>> If that's a misunderstanding, my apologies. If so, then I probably
>> don't need unique modes (but I probably _will_ need parametric
>> bound modes, which on my understanding of the discussion suffer
>> the same problem?)
>
> Again, you don't really need parametric modes for what you want.
>
> The maybe/1 type (or a variant you define yourself) is used
> where a particular field may or may not have been computed.
>
> For example,
>
> 	:- type fitness
> 		--->	unevaluated
> 		;	evaluated(float).
>
> 	:- type individual
> 		--->	individual(
> 				stuff   :: stuff,
> 				fitness :: fitness
> 			).
>
>
> 	:- func new_individual(stuff) = individual.
>
> 	new_individual(X) =
> 		individual(X, unevaluated).
>
>
> 	:- func compute_fitness(individual) = individual.
>
> 	compute_fitness(I) =
> 		( I ^ fitness := evaluated(fitness_of_stuff(I ^ stuff)) ).
>
>
> where compute_fitness/1 fills in the fitness field of an individual.
>
>

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?

	Best Wishes
	Bob McKay

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