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

[Holger Krug]

> 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. Therefore I proposed the concept of
a type, values of which cannot be created by the user.

-- 
Holger Krug
hkrug at rationalizer.com
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------