[m-dev.] Proposal: Sometimes it's safe to assume det=cc_multi

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Aug 7 22:43:53 AEST 2001


On 07-Aug-2001, Holger Krug <hkrug at rationalizer.com> wrote:
> > Oh, right.   Yes, for procedures with io__state pairs,
> > the distinction between det and cc_multi is minor,
> > and could easily be abolished, without any problem for the semantics.
> > (This has been discussed previously on these mailing lists.)
> > 
> > If there is a concensus that the distinction between cc_multi and
> > det for procedures with io__state pairs is more trouble than it is
> > worth, then I'd be willing to get rid of it.
> > 
> > It wouldn't be necessary to change to the compiler.
> > We could just change the determinism of try_io
> > and any other cc_multi procedures in the standard library,
> > and we could provide a procedure
> > 
> > 	:- pred io__choose(pred(T, io__state, io__state), T, io__state, io__state).
> > 	:- mode io__choose(pred(out, di, uo) is cc_multi, out, di, uo) is det.
> > 
> > which let you call a cc_multi io procedure in a det io context.
> > (However, changing the compiler might be desirable, I'm not sure.)
> 
> The problem is, that often (comp. lex.m or aditi.m) io__state is
> encapsulated within other data. So I think it would not suffice to
> restrict this to io__state pairs.

This approach (not changing the compiler) works fine even if the io__state
is encapsulated in another data structure; you just get the io__state out
of the data structure, call io__choose, and the put the resulting io__state
back in.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list