[m-rev.] Section for the Languge Reference Manual

[Volker Wysk]

Hi!

I've summarized what I've learned about optimization that deletes predicate
calls, which may throw an exception. See the recent thread "Existential
higher-order type" in mercury-users.

You might want to include it (or an edited version of it) in the Language
Reference Manual, as a section of the Exception Handling chapter.

In the fourth paragraph ("So what...") I've written my thoughts about what
to do. You might want to skip or rewrite it. 

The desired effect might also be achieved with impurity. I don't have a
paragraph about it, since I'm not sure about it.

Here it is:

----------------------------------------------
Some goals are equivalent to true and don't have any "visible" results. This
means they don't contribute to the computation. But they still may
contribute by throwing exceptions. For instance, an invocation of a
deterministic predicate, which doesn't have any output arguments, can still
throw an exception.

In some cases, such a goal will be optimized away, and its exceptions won't
be thrown. It depends on the optimization level and the chosen language
semantics if this will happen.

The default is the strict commutative semantics. Here such goals will only
get optimized away, when Mercury can derive that the goal always terminates
and doesn't throw an exception. There are other semantics, see chapter "14
Semantics" in the Language Reference Manual. For instance, when specifying
the --no-fully-strict argument to the compiler, it is allowed to optimize
away such goals. See the chapter "9.6 Language semantics options" in the
User Guide. When the compiler is allowed to do so, then it will, in most
optimization levels.

So what if you want to throw exceptions, in goals (such as predicate or
function calls) that otherwise don't have any effect on the computation? You
might want to have a predicate with no output, which checks its input and
throws an exception if it is invalid. And you want to use a semantics, which
allows for optimizing the call away, or you want to be independent of the
used semantics. Then you will have to do it differently. Return an error as
an output argument (use maybe/1) and let the caller throw the exception. If
the caller itself can be optimized away, then let it do the same - return an
error in an output argument, and so on. Until you reach code that
contributes (non-exception wise) to the main computation.

... can it also be done with impurity? ... 
----------------------------------------------


Happy hacking,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20221012/60760623/attachment.sig>