Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!ihnp4!zehntel!hplabs!sri-unix!SHardy@SRI-KL
From: SHardy@SRI-KL@sri-unix.UUCP
Newsgroups: net.lang.prolog
Subject: Built In Predicates
Message-ID: <12420@sri-arpa.UUCP>
Date: Mon, 10-Oct-83 23:50:02 EDT
Article-I.D.: sri-arpa.12420
Posted: Mon Oct 10 23:50:02 1983
Date-Received: Tue, 18-Oct-83 03:43:07 EDT
Lines: 32

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,
   Teknowledge