Re: Ann: SWI-Prolog 7.1.0

"Richard A. O'Keefe" <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
On 27/11/2013, at 7:01 PM, Boris Vassilev wrote:

> The univ operator is, to the uninitiated, a very strange thing. Before I even realized that lists are a nested compound term (which does not seem to be necessary to use them),

Yes, it is.  This is like someone saying "before I even realised that there
was a connection between arrays and pointers in C ...".  You _can't_ use
lists well without understanding what they are, and every ruddy manual and
textbook I've ever seen for Prolog explains that a list
[a,b,c] is just an abbreviation for [a|[b|[c|[]]]] and some of them have
diagrams.

> I sort of expected that one would use lists for "things of the same kind".

That's a sensible way to use lists, and it's enforced by F#, ML, Haskell,
Clean, Mercury, Goedel, and a bunch of related languages.
But it's _not_ the Lisp view, where the _only_ way to write function calls
is (function-name arg1 ... argn) and in Common Lisp the function position
is _not_ evaluated as the arguments are -- Scheme differs there.
> 
> Then you have all of a sudden
> 
> T =.. [F|Args]
> 
> which totally goes against this.

Univ is admittedly a relic of the pre-Cambrian.

> I remember looking for quite a while for a
> 
> univ(T, F, Args)
> 
> and was surprised not to find it.
> 
> So what is it that I am misunderstanding?

The fact that Prolog is an untyped language with strong
historical connections with Lisp.  (Indeed, there have
been several implementations of Prolog _in_ Lisp,
such as LOGLISP
http://aitopics.org/sites/default/files/classic/Machine_Intelligence_10/MI10-Ch20-RobinsonSiberet.pdf
where the J.A.Robinson in question is the inventor of
resolution theorem proving, on which Prolog is based.
There was the LM-Prolog system by Ken Kahn and Mats
Carlsson, who went on to write several other Prologs,
including SICStus.  There was one HP used which I think
was called Q-Prolog.  There are more others than I can
recall.  And of course there's Peter Norvig's one.

A Lisp 1.5 s-expression is
 - a number
 - an atom
 - possibly some other kind of constant
 - or a dotted pair (X . Y)
(a b c . d) is an abbreviation for (a . (b . (c . d)))
(a b c)     is an abbreviation for (a . (b . (c . NIL)))
If you ever wondered why the atom associated with list cells
is ".", this is why.

There was no surprise or astonishment about
[F|Args] "totally going against" anything whatever.
The arguments are terms (analogous to s-expressions).
The function is a term (analogus to an s-expression).
They _are_ the same kind of thing in that world-view.

The fact that L =.. [f(a),g(b)] fails is not really
any different from the fact that L =.. [27,g(b)]
fails; those things _happen_ not to be allowed as 
the function symbol of a compound term.  Practically
_everyone_ associated with Prolog in the early days
had a Lisp background -- I had written two Lisp
interpreters, one in Burroughs Algol and one in
PR1ME Fortran -- and would have been astonished at
the idea of _not_ putting the function symbol "where
it belonged", namely at the head of the list.

Indeed, quite often people were reading and writing
Lisp data in Prolog, and in that case it wasn't that
you _put_ the function in the first position of the
list, that's how the data _came_ to you.  For
example, the Quintus library includes library(kee),
which reads s-expression data written by the
KEE expert system environment.

Lisp and Scheme are still around.
Like Sumerian, there are probably more people who can read
and write Lisp and Scheme now than when they were new...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.