[net.ai] AIList Digest V3 #140

AIList-REQUEST@SRI-AI.ARPA (AIList Moderator Kenneth Laws) (10/10/85)

AIList Digest           Thursday, 10 Oct 1985     Volume 3 : Issue 140

Today's Topics:
  Query - Prolog on Macintoshes and IBM-Style PCs,
  AI Tools - Prolog vs. Lisp

----------------------------------------------------------------------

Date: Wed, 9 Oct 85 17:38:09 mdt
From: ted%nmsu.csnet@CSNET-RELAY.ARPA
Subject: prolog's on macintoshes and ibm-style pc's


Currently I know about arity prolog and prolog-2.  These are
reasonably-featured prolog interpreter/compiler packages that
run on the ibm pc.  Does anyone know of other packages which
are available on the pc or the macintosh???

------------------------------

Date: 05 Sep 85 18:29:55 PDT (Thu)
From: Sanjai Narain <Narain@rand-unix.ARPA>
Subject: Response to Hewitt

          [Forwarded from the Prolog Digest by Laws@SRI-AI.]

>Prolog (like APL before it) will  fail  as  the  foundation  for
>Artificial   Intelligence  because  of  competition  with  Lisp.
>There are commercially  viable  Prolog  implementations  written
>in Lisp but not conversely.

For the same reason, Lisp should have failed as a foundation for
computing because  of  competition  with  assembly language.
There  are commercially viable implementations of Lisp in assembly
language  but not conversely.

>LOGIC as a PROGRAMMING Language will fail as the foundation
>for AI because:

>1.  Logical inference cannot be used to infer the decisions
>    that need to be taken in open systems because the decisions
>    are not determined by system inputs.

>>2.  Logic does not cope well with the contradictory knowledge
>>    bases inherent in open systems.  It leaves out
>>    counterarguments and debate.

>>3.  Taking action does not fit within the logic paradigm.

1.  Hewitt clearly states in his  recent  BYTE  article  that
traditional notions  of  computation  as  defined,  for example,
by Turing machines or recursive functions cannot model the behavior
of open systems.  Hence even Lisp  is  inadequate for such modeling
(by his reasoning).

2.  The notion of contradiction (i.e. inconsistency) is well
understood in logic.

3.  The statement is too vague for debate.  What do the words
"action" and "fit"  mean?   Certainly,  if  action  can  be  modeled
by  an  effective procedure, it can be modeled by logic, cf. 1.

-- Sanjai Narain

------------------------------

Date: Thu, 5-Sep-85 13:40:43 PDT
From: (Tom Khabaza) mcvax!ukc!warwick!cvaxa!tomk@Seismo
Subject: On Hewitt's "Prolog and logic programming will fail"

          [Forwarded from the Prolog Digest by Laws@SRI-AI.]

I have read with interest the discussion following Carl Hewitt's
"Prolog will fail as the foundation for AI and so will Logic
Programming". I particularly enjoyed Vijay Saraswat's reply, most
of which I agree with. However, I would like to add a few comments:

In some ways I was surprised by the original message; I should
have thought that if AI has taught us anything, it is that to solve
a given problem, we need a good representation language.  Why anyone
might think that logic is the BEST representation language for every
problem is beyond me.  (No Kowalskiist flames please, I know the
arguments, and I don't regard the case as proven.)

On the other hand, we don't yet know what the limits of logic
programming are; researchers in the field are constantly coming up
with new techniques.  There is convincing evidence that logic
programming is better than conventional programming for some kinds
of task, at least with regard to ease and clarity (though probably
not yet efficiency).

But I think the basis of the original comment goes deeper than the
virtues and vices of logic programming.  As I understand it (and I
wasn't around at the time) some earlier AI programming languages,
such as perhaps micro-Planner and its successors, WERE expected to
become a "foundation" for AI.  Perhaps this was because people still
had hopes for the notion of some "ultimate" representation language,
or family of languages.

AI is older and perhaps more cynical now; I don't think we expect
some single foundation to the field in the form of a representation
language.  Logic programming may be very useful for some parts of
AI; for example some kinds of rule based systems, but I don't expect
it to be the best tool for all kinds of AI programming.  In fact my
personal opinion is that logic programming will find its forte in
more conventional Computer Science, where formal specification is a
more practical proposition than in the relatively exploratory
activity of AI programming.

But I will say this in its favour: logic programming is IMPORTANT.

Logic programming is as different from conventional programming as
programming is from not programming at all.  I have met people who
have given up on Prolog because it was difficult for them and they
(rightfully) considered themselves competent programmers - and so
thought it must be Prolog's fault!  (I don't mean to imply that
anyone who has posted in this discussion is such a person.) But
logic programming is different in fundamental ways; it's worth
presevering to get to the bottom of it, and as logic programming
languages improve, it will become even more so.

So for all you computer people out there, USE Prolog, and study
how other people have used it.  It really is worth it.

------------------------------

Date: Fri, 13 Sep 85 10:41:27 bst
From: William Clocksin <wfc%computer-lab.cambridge.ac.uk@ucl-cs>
Subject: Lisp/Prolog

          [Forwarded from the Prolog Digest by Laws@SRI-AI.]

I received issues 36 and 37 late owing to netproblem somewhere
between Stanford and Cambridge.  I am puzzled by this Lisp/Prolog
debate started by Carl Hewitt.  I use both Prolog and Lisp, and
have never felt the need to use one exclusively.  I suppose they
are like screwdrivers and chisels;  both are roughly the same,
but for slightly different purposes; to a person unfamiliar with
one of them, the other one might seem redundant.  I am also
puzzled about the question of a "foundation" for AI.  How can a
language be a "foundation" for anything?  Was Latin a "foundation"
of Western civilisation?  Seen any fundamental native speakers
lately? Besides, does AI deserve to have foundations attributed
to it anyway?

Another problem is this question about logic.  Prolog is a
programming language.  It was inspired by logic, but it is not
programming in logic.  Proponents of using logic do have a problem
matching impedance with the real world.  But Prolog is to logic
as Lisp is to lambda calculus.  Those who advocate programming in
lambda calculus have the same problem as those who advocate
programming in pure logic.  If Prolog can be said to have any
connection with logic, it is as the FORTRAN of logic programming.
Prolog is useful because you can grow data structures that have
actual variables in them, and because it is easy to define
nondeterministic methods.  I know how Prolog searches for a solution
just as I know how flow of control happens in Lisp, say.  I am not
disappointed with Prolog's strict strategy just as I am not
disappointed with Lisp's inability to run programs backwards, say.
I take it as it comes, and it is useful for some things.  Talking
hypothetically about the "ideal" language is another topic entirely,
and it only muddies the water to bring Prolog and Lisp into it.

------------------------------

Date: Wed 25 Sep 85 11:22:32-PDT
From: Fernando Pereira <PEREIRA%sri-candide@sri-marvin>
Subject: Prolog vs. Lisp (again!)

          [Forwarded from the Prolog Digest by Laws@SRI-AI.]

I humbly confess my incompetence at the debating style Carl
Hewitt is using in the Prolog vs. Lisp discussions, which
seems to consist in ignoring the FACTUAL points of other
contributions and just continuing to repeat the same OPINIONS.

It is a FACT that no practical Prolog system is written entirely
in Lisp: Common, Inter or any other. Fast Prolog systems have
been written for Lisp machines (Symbolics, Xerox, LMI) but their
performance depends crucially on major microcode support (so
much so that the Symbolics implementation, for example, requires
additional microstore hardware to run Prolog). The reason for
this is simple: No Lisp (nor C, for that matter...) provides the
low-level tagged-pointer and stack operations that are critical
to Prolog performance.

The fact that Lisp is not good enough as an implementation
language for Prolog should not be considered as a weakness of Lisp,
BECAUSE Lisp was not designed for such low-level operations in the
first place. In fact, NO ``high-level'' programming language that I
know of provides those kinds of operations, and for the very simple
reason that, being high-level languages, they have no business in
exploring the recesses of particular machine architectures. ALL
fast Prolog systems that I have seen (some of which I helped
implement) rely on a careful exploitation of the underlying machine
architecture.

By the same argument, the fact that Lisp cannot be efficiently
implemented in Prolog cannot be the basis of a valid criticism of
Prolog. Prolog is not a systems programming language, and in any
case a good Lisp implementation must be carefully coupled to the
underlying machine architecture -- so much so the the fastest Lisps
rely on specialized architectures!

It seems clear to me that no single existing programming language
can be said to provide a ``foundation'' for AI. In fact, the very
notion of a programming language providing a foundation for a
scientific  subject seems to me rather misguided. Does Fortran
provide  a ``foundation'' for physics?  The relation between AI
problems, formal  descriptions and programming concepts is far too
subtle for us to  expect a ``foundation'' for AI in a mere
programming language.

The crusading tone of Hewitt's comments is also rather
unsettling.  AI researchers will use whatever language they
feel most comfortable  with for the problem they are working
on, without need for any  guidance from on high as to the
ultimate suitability of that language. If more researchers use
Prolog, is that a threat to Lisp users? If I do a piece of AI
research using Prolog, will it not be judged according to its
content, independently of programming language?

That kind of battle might be very important for AI software
companies, but surely we should not let marketing hype get in
the way of our research. I am sitting at a Sun workstation typing
this, with a Prolog window just to the right. Will my research be
useless to someone who sits at a Xerox 1109? If I walk down the
corridor and write a Lisp program on a Symbolics machine (as I
have done and surely will continue to do), will THAT work have
a different value? If I decide to use Hoare's CSP for the
navigation component of our robot, will I be then outside
AI, because I am not using an ``official'' AI language?

With respect to Rick McGeer's points: there are some elegant ways
of compiling Prolog into Lisp, particularly into those statically
scoped variety (or into other statically-scoped languages such as
Algol-68...). I have reason to believe that a compiler along these
lines would produce code considerably faster than the 100 LIPS he
reports, even though still much slower than what is attainable with
a lower-level implementation.  [...]

-- Fernando Pereira

------------------------------

Date: Thu, 26 Sep 85 10:29 EDT
From: Tim Finin <Tim%upenn.csnet@CSNET-RELAY.ARPA>
Subject: Lisp and Prolog

          [Forwarded from the Prolog Digest by Laws@SRI-AI.]


                           PROLOG/LISP = LISP/C

I'd like to amplify a point of view Clocksin put forth in V3
#39 in the great LISP vs. PROLOG debate.  Prolog (and Logic
Programming in general) and Lisp are both tools which are suited
for different tasks. Luckily, none of us is being forced to use
one to the exclusion of the other.

I've had to give more than my share of introductory AI talks over
the years. When the discussion gets around to Lisp I usually point
out that Lisp is especially attractive for experimental programming
situations, i.e. where you know what you want to accomplish but do
not yet have all of the details as to algorithms, data structures,
etc. worked out.  Once you've worked out the last detail, you can
re-implement your system in C, if you like, and gain the benefits
of a faster and smaller system.

Along these lines, I think that the slogan "Prolog is to Lisp as
Lisp is to C" is not too inaccurate.  I think that Prolog is even
better suited to initial, experimental and exploratory attempts to
attack a problem computationally.  I find that it is a very
convienent paradigm in which to get started.  Once I have a better
idea of how  to reprent a problem and how to manipulate the
representation, I can  re-implement it in Lisp and gain a faster
more steamlined system.

-- Tim

------------------------------

Date: 9 Oct 85 12:56 PDT
From: Kahn.pa@Xerox.ARPA
Subject: Prolog vs Lisp

Apropos the long debate started by Carl Hewitt:
As co-author of LM-Prolog, the best performing Prolog implemented in
Lisp,  I thought some performance numbers might be useful.   Naive
reverse runs at 10K Lips on a CADR Lisp Machine with special micro-code
support, primarily for unification and trailing.  Without any micro-code
support it runs 2 to 3 times slower.  While there are much faster
Prologs available, I would argue that LM-Prolog is commercially viable
without the micro-code.  There have been sales of the 3600 version of
LM-Prolog despite the fact that it is not supported by micro-code.

But part of Fernando's counter to Carl was that a serious Prolog
implementation needs sub-primitives that Lisp does not provide.  It is
true that LM-Prolog even without micro-code relies on Zeta-Lisp's
sub-primitives to manipulate pointers and create invisible pointers.
This makes de-referencing variables very fast.   While I don't have any
figures I don't think that is so important, at least for the naive
reverse benchmark.  In other words I believe a pure Common Lisp
implementation of Prolog on say a 3600 would run 3 or 4 times slower
than Symbolics Prolog (which is fully micro-coded).  Depending upon how
important a factor of 3 or 4 is, one evaluates differently Carl's claim
that Lisp is good for implementing Prolog (and not vice versa).

I think part of this whole debate is confused with the larger debate of
single paradigm vs multi-paradigm languages.  My feeling is that while a
single paradigm system is elegant that too often it doesn't fit the
problem well and ackward cliches are used.  For example, it is widely
believed that for some kinds of problems object-oriented programming is
most appropriate because it encasulates state and behavior so well.

Concurrent Prolog advocates in such situations program objects in a
complex cliche of tail recursive predicates where one argument is a
stream of messages.  No serious object-oriented language requires that
each method list all the instance variables in the head and their new
values again at the end of each "method" (the tail recursive call).  I
am not happy with the argument that goes -- well some problems are best
programmed with Lisp, others with Prolog, others with SmallTalk, and
still others with Ops5.  Any significantly large problem is going to
have sub-problems that are best handled by different paradigms.

The debate should not be Lisp vs. Prolog but how can we combine Lisp and
Prolog (and Smalltalk and ...) in a coherent well-integrated fashion.
Its not easy.  LM-Prolog was one attempt at doing this, as well as
ICOT's ESP,  Prolog-KR and LogLisp.  I tried to integrate Prolog with
Loops.  None of these integrations are perfect but I think this is the
direction to go for BUILDING TOOLS for BUILDING REAL APPLICATIONS.  The
CommonLoops effort at Xerox represents to me the best effort to date to
build a tight integration of two paradigms (object and
procedure-oriented).

In contrast, to what I just said I think the single paradigm approach
can be a great research strategy.  Much of the Logic Programming
community is caught up in the game of finding out how far can one go
with logic programming.  Can one write simulators, text editors,
graphics, operating systems, embedded languages, and so on in Prolog
or a language like it?  It is rightfully considered cheating to
"escape to Lisp" or jump into some object-oriented subsystem.  Their
purpose is to explore the paradigm itself -- its uses, its
limitations, to stretch it and pull it in new directions not to build
real applications.  When building real applications the question is
not can this or that be done in Prolog, we all know that everything
can be written in Prolog, but what language can give the best support
for building the application in the most fitting way.

------------------------------

End of AIList Digest
********************