[mercury-users] Another Mercury Modes Problem

[Bob McKay]

Firstly, thanks Ralph (and others). My apologies for the stuff-up
re list/list_skel; I knew about list_skel, but simply forgot (which I
guess reinforces Michael's point.

On Tuesday, May 28, 2002, at 02:01 PM, Ralph Becket wrote:

> You haven't given enough information for us to offer much help.

Apologies for that; it's kind of hard to guess how much to give, you
presumably don't want the whole code, and localising is slow because
I'm still at the stage of being unsure what is relevant.

>  There
> are a number of problems here; here's what I can come up with (I've
> added some cleaned up bits of code that I wrote to help me think):
>
>
> Why do the lists have to be unique?  This is probably going to be a
> source of pain.

Well, they're the GA population; I'm going to want to re-use the
space presumably, and my understanding is that this is what a
unique declaration permits the compiler to do (though I think the
manual says this is currently unimplemented).
>
> Problem: list/1 is not a data constructor or a parametric inst.  You
> probably mean list_skel/1.

Yup.
>
> We'll use modes di/1 and uo/1 for these insts where necessary to
> indicate uniqueness (see next.)
>
>> :- mode create_ind == free >> init_individual.
>> :- mode eval_ind == free >> individual.
>> :- mode create_ind_list == free >> init_individual_list.
>> #:- mode eval_ind_list == free >> individual_list.
>
> Use built-in modes in, out, in(I), out(I), di(I), and uo(I)
> for I in {init_individual, individual, init_individuals, individuals}
> in preference to your named modes (it's better to have mode names that
> make the direction of data flow clear.)
>
>     % These should be built-in, but aren't...
>     %
> :- mode di(I) == unique(I) >> dead.
> :- mode uo(I) ==      free >> unique(I).
>
>> :- pred eval_ind(individual,individual,
>> 	message,message,supply,supply).
>> :- mode eval_ind(in,eval_ind,out,out,mdi,muo) is det.
>
> Tip: spaces after commas makes a big difference to readability.
>
> [clean up:]
>
> :- pred eval_ind(individual, individual, message, message, supply, 
> supply).
> :- mode eval_ind(in, out(individual), out, out, mdi, muo) is det.

Thanks for these ideas. I must admit, I hadn't really got parametric
modes clear in my mind.
>
>> :- pred eval_population(list(P),list(P),list(message),
>> 		pred(P,P,message,message,supply,supply),
>> 		supply,supply).
>> :- mode eval_population(in,eval_ind_list,out,
>>   in(pred(in,eval_ind,out,out,mdi,muo)is det),mdi,muo) is det.
>
> Several problems here.
>
> Tip: it's a good idea to name complex higher order types and modes:
>
> :- type eval_pred(T) == (pred(T, T, message, message, supply, supply)).
> :- inst eval_pred    == (pred(in, uo(individuals), out, out, mdi, muo) 
> is det).
>
> This is for the pred(...) argument to eval_population/6.
>
> Problem: the first two arguments are polymorphic, but the second mode
> applies only to type list(individual).  This is clearly wrong.  Do you
> mean `individuals' rather than `T'?  Or should you be using type classes
> instead (in which case we need to be a bit more sophisticated...)  Let's
> assume the former, so the correct declarations are
>
> :- type eval_pred == (pred(individual, individual, message, message,
> 				            supply, supply)).
> :- inst eval_pred == (pred(in, uo(individual), out, out, mdi, muo) is 
> det).
>
>
> :- pred eval_population(individuals, individuals, messages, eval_pred,
>                             supply, supply).
> :- mode eval_population(in, uo(individuals), out, in(eval_pred),
>                             mdi, muo) is det.

Yep, this is what I meant.
>
>> #eval_population([],[],[],_) --> !.
>> #eval_population([IUneval|IUnevals],[IEval|IEvals],
>>   [Indmessage,Fitmessage|Messages],Process) -->
>>         Process(IUneval,IEval,Indmessage,Fitmessage),
>>         eval_population(IUnevals,IEvals,Messages,Process).
>
> Problem: !/0 is an old Prologism, has no meaning in Mercury (it is
> currently defined as true), and will go away in the near future (it is
> being used for state variable syntax.)
>
> Here's something that should work:
>
> eval_population([],            [],          [],            _,     S,  
> S).
>
> eval_population([U | Unevals], [E | Evals], [I, F | Msgs], EvalP, S0, 
> S) :-
>     EvalP(U, E, I, F, S0, S1),
>     eval_population(Unevals, Evals, Msgs, EvalP, S1, S).
>
Actually, true is fine for me. Since I'm using DCG's as far as
possible consistently throughout for passing the random seed (except
at the top level, where I need to use it for the I/O state), I'd like
to stick with the DCG notation.

	Best Wishes
	Bob
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------