🚀 go-pugleaf

In article <1328@n_kulcscs.kuleuven.ac.be>, bimbart@habakuk.cs.kuleuven.ac.be (Bart Demoen) writes:
>The standard should specify how a builtin predicate can be called 'correctly'
>and the effect of such calls (most 'correct' calls succeed, but there is nothing
>against deciding that calling arg/3 with a negative first argument is not an
>error and defining the behaviour as fail)
>ALL other calls should silently fail if debug is off (the behavior of a Prolog
>system when debug is on, is not standardized)

Any clear principle is a long way better than none.
I would rather use a system defined in accordance with Demoen's rule
than something bodged together inchmeal.

However, this has to be said:  failure is NOT a good way of reporting
exceptions.  In Prolog, 'fail' is *normal* behaviour for many
predicates.  For example, if I call read(a) and the next term in the
current input stream is "b. ", the result is properly a failure.
How would you regard a programming language where the error reporting
behaviour for all the math functions was to return 2.0, so that
sqrt(-47.0) = 2.0, tan(pi/2) = 2.0, arcsin(29.0 = 2.0, and so on?
That's a pretty fair analogue of making Prolog EPs report errors by
failing quietly.

> This is sensible for running applications - they typically have debug off ...

It is necessary to distinguish clearly between two things:  signalling
in some program-detectable fashion that an exception has occurred, and
reporting in some human-comprehensilbe fashion which exception has
occurred (and perhaps providing the opportunity to intervene).  'debug'
refers to HUMAN interfacing and intervention.  I've forgotten which
famous computer scientist it was, but switching off error detection in
shipped applications has been described as "wearing a life jacket while
you're in the harbour, but throwing it away when you're out on the open
sea."  It is *precisely* running applications, where the end user has
no access to the source code, where it is *especially* important that
exceptions should be signalled to a program as I recommended in a
document sent to the BSI committee in 1984 (signal_error(ErrorTerm)
and if_error(Goal, ErrorTerm, Handler) -- I'd now put the ErrorTerm
first in if_error/3, and it would of course be nearly as stupid to
use ATOMS as error terms as it would to use integers).  That proposal
was borrowed more or less directly from Ada and ML.  The scheme in C++
is similar.

Detecting exceptions in EPs and reporting them _to the program_ is
not a debugging issue!

> This is sensible for optimising compilers and for program analysis.

I would point out that Ada and PL/I have run-time error detection with
errors being signalled _to the program_ and it doesn't seem to hurt their
optimising compilers much.  It would hurt a Prolog optimising compiler
less than error=failure would.  Consider
	p(X) :- see(X), q, fail.
	p(X) :- close(X).
If exceptions are signalled, an optimising compiler can assume in the
second clause that X is an atom (or a string; at any rate that it is
ground).  if errors are confounded with failure, a compiler does not
have this opportunity.  It is easy to construct other examples like this.

> You can have error messages in debug mode - the only mode they make sense in.

Signalling errors _to the program_ does not involve error messages.
Ada and C++ have exception handling without having error messages.

-- 
Fear most of all to be in error.	-- Kierkegaard, quoting Socrates.