[m-dev.] not_reached inst

[Ian MacLarty]

On Wed, Apr 11, 2007 at 05:57:09PM +1000, Zoltan Somogyi wrote:
> On 11-Apr-2007, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> > Actually if I try this it doesn't do what I expect.  I get a determinism error
> > for the mode :- mode p(in(d), out(c)) is det.  I don't expect a determinism
> > error, because, as I understand it, this mode of p could never be called, so it
> > shouldn't really matter what determinism I give.
> 
> The compiler doesn't ignore errors from dead procedures. Making it ignore
> errors from dead procedures is possible, but I would think having an error
> suddenly pop in code that was always in a program but became non-dead due
> to a recent change would violate the principle of least astonishment.
> 

I'm not saying that errors for dead procs should be ignored, what I'm saying
is that perhaps there is no determinism error with the following:

:- pred p(string::in(not_reached), string::out) is det.

p("a", "b").

In the reference manual it says:

  If all possible calls to a particular mode of a predicate or function which
  return to the caller (calls which terminate, do not throw an exception and do
  not cause a fatal runtime error)

    * have exactly one solution, then that mode is deterministic (det);
    * either have no solutions or have one solution, then that mode is
      semideterministic (semidet);
    * have at least one solution but may have more, then that mode is
      multisolution (multi);
    * have zero or more solutions, then that mode is nondeterministic (nondet);
    * fail without producing a solution, then that mode has a determinism of
      failure. 

  If no possible calls to a particular mode of a predicate or function can
  return to the caller, then that mode has a determinism of erroneous.

By this I'd say that the procedure above could legally have any determinism
(including errorneous), since there are no possible calls to the procedure at
all (whether they return to the caller or not).

Ian.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------