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...