🚀 go-pugleaf

In article <1804@ecrc.de> micha@ecrc.de (Micha Meier) writes:

> So, e.g. if you want an undefined procedure to fail, you would write
> instead of p(X)
>
> 	block(p(X), Something, fail)
>
> in *all* places where p/1 might be undefined.

In Vienna (ISO meeting this spring), I used that as one of the arguments against
this mechanism: it was discarded ... silently .


In article <ALBERTO.90Oct25134549@yamuna.cs.umd.edu> alberto@cs.umd.edu (Jose Alberto Fernandez R) writes:

> I propose a more simple and flexible mechanism that has been used
> already in Prolog. The mechanism used by print-portray.

> The idea is that when an error occurs intead of fail, produce an
> exception o send a message, the code calls a predicate error_handler/1
> defined by the user.

(and the argument for error_handler/1 is presumably the call in error with its
arguments as they were at the moment of the call ?)

I was referring to this mechanism in an earlier message, when I said something
about an ideal but non-implementable error handling: at the moment an error is
detected, the state of the Prolog engine (local stack or heap or whatever) might
be inconsistent with 'calling another predicate'; and keeping the necessary
information to recover from this inconsistent state might be too costly; that's
why 'unwinding the stack' is the compromise: just like failure, it makes the state
consistent again, so that a call can be made; 

Other mechanisms have been proposed - e.g. by Gerald Karam in Ottawa - and they
are all very nice in interpreters, but not feasable in optimised systems: after
all, ancestor_cut is a 'nice' feature as well, but have you seen it around lately ?

Bart Demoen