SHardy@SRI-KL@sri-unix.UUCP (10/11/83)
I disagree with the proposal that built-in predicates should emulate
tables of assertions.
To summarize, this view states that if Prolog provides a predicate
such as SUCC then it should act as if defined by a table, thus:
succ(1, 2).
succ(2, 3).
succ(3, 4).
etc
Calls to succ such as:
succ(foo, X).
should, according to this view, simply fail.
Chances are that if my Prolog program ever executes the above
call, it's n error. The very last thing I want a programming
system to do when I've made a mistake is to execute some more
or less random non-local GOTO - which is what an unantipated
fail usually amounts to.
Crucially, we have to decide whether Prolog is a practical
programming language (and so subject to occasional compromises)
or a concept too pure to be sullied by practical considerations.
The ``principal'' by which implementors make decisions should
be ``what helps the user''.
-- Steve Hardy,
Teknowledgebarmar@mit-eddie.UUCP (Barry Margolin) (10/18/83)
Perhaps built-in predicates should be defined as if they were: succ (1, 2). succ (2, 3). . . . succ (_, _):- error (). Where error () is a built-in predicate which causes the program to abort with an error message (perhaps a real version of this would take arguments specifying what the message should be). At some level, of course, you have to have primitives which really can't be defined in the language. I have replaced succ with error. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar