lagache@violet.berkeley.edu (Edouard Lagache) (04/02/88)
I have reading the latest exchanges on the proposed BSI
PROLOG standard with alarm and despair. Like Richard
O'Keefe, I have been monitoring the miserable state of
affairs surrounding the proposed FORTRAN-8x standard, and I
am seeing a similar disregard for the "in the trenches"
PROLOG programmers in the framing of BSI standard.
I am *very* concerned about any proposal to change the
meaning of predicates as fundamental as 'atom'. The change
that Richard was discussing seems to me be very bizarre
indeed. Because I am developing educational applications in
PROLOG, I want to be able to retain complete control over the
execution of my program. Thus, I don't want the d**n system
interrupting the logic of my program with error conditions
that are in effect another kind of logical condition.
In LISP it is possible to trap errors, thus, you can
always keep control of your program "no matter what". PROLOG
has no such capability and it probably just as well since
error trapping couldn't be implemented in a very "logical"
way (in the PROLOG flow of control sense of logical).
If we don't have error trapping, then how are us weary
overworked programmer supposed to keep control of our
programs when those ingenious fools out there finally find
our bugs. Sure, good code doesn't need such expedients, and
if you are willing to pay me to spend another 5 years getting
my master's maybe I will produce some of that fabled "good
code". Real code, like the real world, is imperfect.
Given the fact that any PROLOG predicate has a perfectly
good way to deal with _any_ situation it encounters (just
plain fail), I cannot say I am at all sympathetic to
increasing the number of ways that one can generate an
runtime error message in PROLOG. While it may be less
"logical" to not generate an error message when attempting
test if an unbounded variable is an atom, I am not convinced
it is any less logical than to not report an error message
when one attempts to query the database for a non-existing
clause.
Indeed, I think that this is another example of trying
to ask PROLOG to be something it cannot be: programming in
pure logic. While there are some cases of failure that can
be interpreted as false in the classical logic sense of the
term. others such as a database query failure must be
interpreted as precisely that: a failure to satisfy. We
cannot make a programming language that permits programming
in pure logic, but we can make a very powerful programming
language if we use logic as a model, *but* accept the real
limitations imposed by our technology.
While this is clearly a radical view, I could certainly
see an implementation of PROLOG with no runtime errors at
all, and were the failure of a predicate would mean only that
the predicate couldn't be satisfied irregardless of the
reason. Doing so reduces the amount of information that the
programmer has to work with, but in return he/she is given
far more control over the execution of his/her code, and the
problem of error trapping would be solved in a very logical
fashion (depending on how one interprets the meaning of
logical).
Ok frame away, but I hope people see my point. If
PROLOG is going to become a real language (and not a
researcher's plaything) it is going to have to become robust
enough to handle a wide range of situations that it is poorly
suited to deal with now.
<*** Flames on ***>
What the BSI people should be up is worrying about how to
make PROLOG more practical. I don't give a d**n about
subtleties of logic, because no matter what you do, you cannot
turn PROLOG into pure logic programming. What I want from
the BSI people is turn PROLOG from an interesting research
tool into a hardened, robust programming language that can be
taken out in a world of "mad scientist" programmers and
ingenious neophile users and put to work in the trenches. To
do that means worrying about how to trap user errors, how to
produce good input/output, how to get the system to run on
Commodore-64s (God I hope not, but they are still using
those things in the schools!), and how to make this language
reasonable easy to learn, use, and maintain. Worrying about
those factors will make the difference between PROLOG's long
term survival, and it short term disappearance. Come on
folks, if you really want this language to survive, then it
is time to stop worrying if its hair is combed straight, and
time to make sure that its teeth are good and sharp!
<*** Flames off ***>
[boy, am I going to get it for this note!]
Edouard Lagache
PROLOG Forum
lagache@violet.berkeley.eduok@quintus.UUCP (Richard A. O'Keefe) (04/02/88)
In article <8231@agate.BERKELEY.EDU>, lagache@violet.berkeley.edu (Edouard Lagache) writes: > [boy, am I going to get it for this note!] Not from me, you're not! In fairness to the BSI committee, error handling has been one of their concerns from the very first, and they have adopted a solution which is similar to that in IF/Prolog, except that IF used sensible names for the operations. [As a matter of fact, the solution they have adopted is very similar to what I suggested in a document I sent to the BSI group in 1984, entitled "Notes on the Standard". I have often wondered why this document was not included in the BSI Document Register.]