[mercury-users] re: determinism question

[Fergus Henderson]

On 04-Nov-1998, Don Smith <dsmith at cs.waikato.ac.nz> wrote:
> 
> [Fergus wrote:]
> I declare a procedure "det"; by looking just at the definition of
> that procedure, and at the type, mode, and determinism declarations
> of other procedures, the compiler can't prove that it is deterministic.
> Is it fair to look at the other procedures' definitions as well?  Within 
> a module, I'd say "Yes!"    The compiler's ability to verify determinism
> declarations can never be perfect, but all sorts of inter-procedural
> information should be accessible, including the specific clauses used.

So, you agree that doing this across module boundaries would violate
encapsulation, but you think doing it within a module would be OK.
I think this reasoning is based on the assumption that the module
is the only unit of encapsulation.  But I think that there are advantages
in allowing predicates and functions to be units of encapsulation too.
In particular, I think it makes maintenance easier.  For example,
the programmer can make meaning-preserving changes to a predicate,
and can be sure that those changes won't affect the legality of
other predicates in that module.  Another example is the advantage
I referred to earlier: it's easier to move predicates from one module
to another.

If you treat the module as the only unit of encapsulation, then yes
it would be fair to make determinism checking do interprocedural analysis
within a module.  But if you treat functions and predicates as units
of encapsulation too, as I think you should, then it wouldn't be fair.

(Of course even if it were fair, that wouldn't necessarily mean it
was beneficial.)

> Accessing that information [for determinism analysis] is not an
> "optimization";

Agreed.

> > For example, you don't want to transform a terminating program
> > into one that doesn't terminate.  Nor do you want to transform ...
> > 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.

The "So" here was refering to the part you elided from that quote:
you don't want to transform a program that works into one that doesn't,
hence the transformations need to preserve mode-correctness and
determinism-correctness.

> I don't see how doing optimizations within a module could lead to errors
> of these sorts.

I wasn't talking about optimization within a module there;
I was saying that in general, the meaning-performing transformations
that declarative programming languages seek to allow
must also preserve these qualities.  That's why you should not be
surprised that replacing your original example program with the
logically eqivalent but not determinism-correct one didn't work:
you need to check (or at least let the compiler check)
that your transformation preserves determinism-correctness.

Correct optimizations of course do indeed preserve mode-correctness
and determinism-correctness.  But it's easy to imagine buggy
optimizations that don't...

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