[mercury-users] cc_multi vs det

[Peter Ross]

On Fri, Dec 01, 2000 at 10:07:09AM +1100, Tyson Dowd wrote:
> On 30-Nov-2000, Peter Ross <peter.ross at miscrit.be> wrote:
> > On Thu, Nov 30, 2000 at 04:08:25PM +1100, Mark Anthony BROWN wrote:
> > > 
> > > Because there may have been more than one potential exception, and
> > > the Mercury implementation may have (operationally) chosen one of
> > > them.  In code that handles exceptions, it is possible that different
> > > exceptions lead to different solutions, so the Mercury implementation
> > > may effectively be making a choice between two different solutions in
> > > the higher level predicate.  This is (declaratively) modelled using
> > > committed choice nondeterminism.
> > > 
> > I understand the declarative differences between cc_multi vs det.
> > 
> > However I am not sure what effect these declarative differences have on
> > the generated code.  Could someone give me an example of when the
> > distinction between cc_multi and det is important when the code is
> > generated (ie where having det instead of cc_multi leads to incorrect
> > code).
> 
> The generated code is exactly the same.
> 
> >From code_model.m in the compiler source:
> 
> determinism_to_code_model(det,         model_det).
> determinism_to_code_model(semidet,     model_semi).
> determinism_to_code_model(nondet,      model_non).
> determinism_to_code_model(multidet,    model_non).
> determinism_to_code_model(cc_nondet,   model_semi).
> determinism_to_code_model(cc_multidet, model_det).
> determinism_to_code_model(erroneous,   model_det).
> determinism_to_code_model(failure,     model_semi).
> 
> cc_multi is the same code model as det.
> cc_nondet is the same code model as semidet.
> 
> The correctness of the solutions will be the same, but there is a
> difference between a program which has `main' as det or cc_multi.  A
> cc_multi program might behave differently (compute different solutions,
> and produce different IO as a result) even given the exact same starting
> conditions.  A det program will not.
> 
OK.

One of the problems with cc_multi is that it propogates quickly, which
can be a real pain.

Say I develop some code which is det.  I then integrate this with some code
that is cc_multi, I must then propogate the cc_multi all the way up the
call chain, which is a real pain.  So my question is, can not
propogating this information up the call chain ever lead to a situation
where the generated code is incorrect (ie the compiler does the wrong
thing currently, treating cc_multi code as det).

In other words is the cc_multi information only useful from a semantic
view point, but in practice doesn't really have much effect.

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