Path: utzoo!utgpu!watserv1!watmath!att!att!bu.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Standards question: behavior of arg/3
Keywords: ANSI, standard
Message-ID: <4142@goanna.cs.rmit.oz.au>
Date: 30 Oct 90 04:31:52 GMT
References: <9888@bunny.GTE.COM> <3992@goanna.cs.rmit.oz.au> <1753@ecrc.de> <1990Oct29.042755.18583@cpsc.ucalgary.ca>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 74

In article <1990Oct29.042755.18583@cpsc.ucalgary.ca>, cleary@cs-sun-fsc.cpsc.ucalgary.ca (John Cleary) writes:
> I very glad to see some real discussion of errors in Prolog.
> This topic is important and I have not yet seen any principled and
> acceptable solution.

What is unprincipled about the if_error/3+signal_error/1 scheme I
proposed to the BSI in 1984?  (The present exit_block/3+block/1 in
the current draft is my scheme plus an entirely incomprehensible
name change.)  What's wrong with the scheme in NU Prolog?  (The
difference between the NU Prolog scheme and my scheme is that my
scheme undoes variable bindings just like 'fail', while NU Prolog's
doesn't, the difference has to do with the possibility of constrained
variables appearing in ErrorTerms.)  What is unprincipled about the
scheme in ALS Prolog (catch/2 and throw/1; I'm not sure if it's like
the NU Prolog scheme or my 1984 scheme)?  There is a great deal to
dislike about the error handling stuff in IBM Prolog, but what don't
_you_ like about it?

> However, it is worth noting that the question is not as simple as it seems.
> Consider for example is.
> 
> Now
> 	X is fred
> should clearly generate an error message :-).  But at least once in my career
> I desperately wanted it not to.  I wanted to use is to test whether an 
> expression was a valid arithmetic expression.

In the context of user-extensible arithmetic (something that many ISO
contributors have wanted, and it has been part of several drafts) it is
NOT clear that
	X is fred
should generate an error message; it would be equivalent to
	fred(Y),
	should_be(number, Y, Y is fred),
	X = Y
and if for example
	fred(27)
happens to be true it would not be an error.

In my 1984 proposal to the BSI, this would have been done thus:

	if_error(_ is fred, _, fail)

I now believe that the ErrorTerm should be first (so that it is the
first argument of both the error-related commands).  Furthermore, we
only want to catch type failures.  So

	if_error(type_failure(_,_,_,_), _ is fred, fail)

Note that it is possible to make setting up an error handler very cheap.

You have raised an important point:  there are two alternative approaches
to error handling:  detection and prevention.  My favourite example is
opening files.  If there is an operation "would I be allowed to open
file F for operations O", then I don't need to handle errors in open/3.
But then we run up against the need for lots and lots of "would it be
ok to do X" predicates.

> As for 
> 	2 is Y+3
> there are number of systems quite able to deduce that Y is 1.

Any Prolog system that does that is ****WRONG****.  There are in fact
*INFINITELY* many solutions for Y: Y = 1, Y = 0+1, Y = 1*1, Y =
0+1*1, Y = 0*2+1*1, ...  If you want invertible addition, use
	plus(X, Y, X_plus_Y)

> So come on some genius out there give us a good clean solution to this 
> problem of errors.

Well, tell us what's wrong with the one we've got!
-- 
The problem about real life is that moving one's knight to QB3
may always be replied to with a lob across the net.  --Alasdair Macintyre.