[m-dev.] call for opinions on promise_same_solutions syntax

[Mark Brown]

And a couple of addenda:

On 27-Feb-2006, Mark Brown <mark at cs.mu.OZ.AU> wrote:
> On 27-Feb-2006, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > On 27-Feb-2006, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:

...

> > In this case, either way you do it, the promise is wrong, because calling
> > set_mutable isn't a pure computation. In other words, you lied to the compiler,
> > so it is entitled to its revenge.
> 
> Well, yes.  But there are better examples to illustrate the point.  For
> example, replace `set_mutable' with `unsafe_write_int'.  In that case,
> putting the promise in the body would be a lie, and promise_equivalent_clauses
> would not be applicable.  But p/2 would be pure because all it does is modify
> the IO state, and io.state appears in its arguments.

A while ago we had a discussion in the office about what exactly you are
allowed to do when modifying the state of the world.  It can be argued that
the contents of memory are part of this state, and therefore that changing
a mutable is a legitimate I/O operation.  For the record, I don't think
we should be given carte blanche on this -- there are more things in heaven
and earth than are encapsulated in the io.state -- but AFAIK we've never
formalised what is allowed and what isn't.

> 
> > 
> > > <http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-reviews/mercury-reviews.200512/0052.html>
> > > 
> > > Any discussion of adding `promise_equivalent_clauses should take place as
> > > part of this.
> > 
> > Ok, I'll review that and set up a time to hash it out.
> 
> In particular, see:
> 
> <http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-reviews/mercury-reviews.200512/0074.html>
> 
> Your proposal would address the concern I raised there, but not the one Julien
> raised here.

To be clear, I'm not objecting to the new pragma, just to the removal of the
existing mechanism.  Although I don't think they should be called pragmas --
see the aforementioned thread.

Cheers,
Mark.

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