[mercury-users] re: determinism question

[Fergus Henderson]

On 03-Nov-1998, Don Smith <dsmith at cs.waikato.ac.nz> wrote:
> >If it did that, then the determinism-correctness of p/1 would depend
> >not only on the declarations of p0, p1, p2, and p3, but also on their
> >definitions.  This would be a violation of abstraction -- the
> >declarations (and documentation) should specify the interface, and
> >callers should depend for their correctness only on the documented
> >interface, not on the implementation details.
> 
> I could agree with your attitude when it comes to respecting the
> abstraction of a module by not depending on any particular details of
> the implementation of its declared interface.  But within a module, all
> sorts of inter-procedural optimizations seem like fair game to me.

Certainly all kinds of inter-procedural optimizations are fair game.
But I don't think the legality of a program should depend on optimizations.
The compiler should check the legality first, and then optimize afterwards.

Also, having one rule for procedures within the same module and
a different rule for procedures in different modules would make
it more difficult to move procedures from one module to another.

> After all, one of the major advantages of declarative programming is
> supposed to be that we can do all sorts of meaning-preserving
> transformations based on semantic equivalence.

Well yes, but the result of such transformations had better satisfy certain
conditions.  For example, you don't want to transform a terminating program
into one that doesn't terminate.  Nor do you want to transform a
working program into one that doesn't work, or an efficient program into
an inefficient one.  So the transformations should preserve
mode-correctness and determinism-correctness: you don't want to
transform a mode-correct program into one containing mode errors, and
you don't want to transform a determinism-correct program into one
containing determinism errors.

Preserving mode-correctness applies even more strongly in Prolog
than in Mercury, since in Prolog mode errors can lead to incorrect
behaviour at runtime, whereas in Mercury you get a compile error.
Preserving determinism-correctness is perhaps less important in
Prolog, since in Prolog if a transformation preserves logical
equivalence and mode-correctness but reduces the compiler's ability
to infer determinism, then the effect is just a performance loss,
whereas in Mercury the effect is a compile error.  But arguably
a compile error is better than a subtle performance bug anyway.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.