🚀 go-pugleaf

some reactions to
	<4052@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
	<11521@alice.att.com> pereira@alice.att.com (Fernando Pereira)
	<4055@goanna.cs.rmit.oz.au> (Richard A. O'Keefe)


> "wearing a life jacket while you're in the harbour, but throwing it away when
> you're out on the open sea."

I agree that's is pretty stupid thing to do, but to have quiet failure of a builtin
predicate in error, is not like having nothing at all 

> Running applications *do* have bugs, and silent
> failure will make those bugs extremely difficult to report.

silent failure is not useless: if the mechanism of reporting errors (to the running
application) is by exit_block/1, the application has to be programmed that way;
if the the mechanism is silent failure, the same holds;
it is the difference between writing


		... , block(arg(N,Term,ArgN),error(Type,_),handler(Type)) , ...

and writing

		... , (arg(N,Term,ArgN) -> true ; handler(...)) , ...

and whether one looks nicer or more structured than the other, is not the point, the
point is that silent failure is of use; and whether the application writer
wants to exploit silent failure always or not, is her business, while if the
standard requires all errors to behave in the longjmp fashion, the programmer must
defend herself against such a thing continuously

perhaps the issue is not which mechanism is better, but rather which errors should
have which recovery mechanism; to decide this, a classification like "disasters,
faults,errors,failures" (yes, we keep a copy of such stuff) might be more helpful
than the current classification of the draft standard, which treats all errors 
equally - with the exception of "system error" to which the Prolog processor is
allowed to react in an implementation dependent way

> How would you regard a programming language where the error reporting
> behaviour for all the math functions was to return 2.0
good joke - who implemented that ?

> That's a pretty fair analogue of making Prolog EPs report errors by
> failing quietly.

it enforces my belief that not all errors (as descibed in the draft
right now) should be treated in the same way


> The reasonable response is to raise an
> exception. Such exceptions might be caught by handlers that then proceed
> to fail silently, but by default uncaught exceptions will arrive back
> at some top level and be reported.

it is not really possible to enforce silent failure with the current draft, unless
by wrapping every call to a builtin predicate in a call to block/3, which is very
inconvenient and inefficient; still, silent failure is in many circomstances very
useful and there should be a way to get it at a low price

the current draft looks to me like a compromise between the people who would
ideally like all erroneous calls to builtin predicates to be replacable by any
other (user defined) call (without unwinding the stack as exit_block/1 does) and
those people who believe that such a thing is (almost - to be careful) not
implementable in an efficient way (in debug mode it is of course possible)


Bart Demoen