PROLOG-REQUEST@SU-SCORE.ARPA (Chuck Restivo, The Moderator) (10/22/85)
PROLOG Digest Tuesday, 22 Oct 1985 Volume 3 : Issue 43
Today's Topics:
LP Philosophy - Hewitt's Challenge,
Implementation - Destructive Assignment,
Announcement - Third ICLP,
Puzzles - Games & Fun
----------------------------------------------------------------------
Date: Thu, 17 Oct 85 16:46:21 bst
From: William Clocksin <wfc%computer-lab.cambridge.ac.uk@ucl-cs>
Subject: Lisp in Prolog
One of Carl Hewitt's recent comments concerns writing a Lisp
system in Prolog. It has subsequently been argued by
contributors that Hewitt's comments are irrelevant to Prolog
as a foundation for AI (whatever "foundation" means anyway).
I agree with them, but setting that aside for a moment, it
cannot have escaped the attention of most people that writing
a compiler (in Prolog) to COMPILE Lisp into some target (say LAP)
would be as easy as pie. For those of us who have written
compilers in both Lisp and Prolog, I daresay it would be a lot
easier in Prolog. I might further suggest that the compiler
test is more useful than the interpreter test, and that the
interpreter test has no especial theoretical advantage, since
the compiler can be seen as a meaning-preserving transformation.
(Ahem. Which in fact it isn't for Lisp if you're not careful
with bindings).
------------------------------
Date: 9 Oct 85 12:56 PDT
From: Kahn.pa@Xerox.ARPA
Subject: Destructive assignment
First I would like to comment on Paul Hudak discussion on mutable
arrays and elaborate on an earlier point by Fernando.
A couple years ago I implemented mutable arrays in LM-Prolog. The
idea is that an update predicate have arguments for both the old and
new version of the array being changed. The semantics of the
predicate was given as a straight-forward but expensive simulation
of arrays using lists and updates using copying. The implementation
was, of course, free to represent the versions of the array in any
way that maintained the semantics of the predicate.
The most common representation was a perfectly ordinary array for
the most recent version and for the old version a data structure
representing the old values for component that have changed and
pointer to the newest version. The details of all this can be
found in the paper by Lars-Henrik Eriksson and Manny Rayner in the
proceedings of the Second International Logic Programming Conference
held in Uppsala Sweden 1984. As Paul points out that when the old
version is not referenced after the update that a compiler can
optimize even that overhead away.
Concurrent Prolog has an even more direct way of programming as if
one had destructive assignment by relying on tail recursion
optimization. But both schemes and the one that Fernando talked about
earlier have one deficiency/ackwardness. Namely, a "pointer" to a
mutable data structure does not see any changes since they continue to
point the old version. As Fernando points out to get around this one
needs to start at the top of any system of data structures. In
Concurrent Prolog one avoids this problem in a different ackward
manner -- every time in a conventional program with side effects that
one "passes out" pointers one needs to explictly call "merge" to split
the references.
------------------------------
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 commerically 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 sub-system. 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.
------------------------------
Date: Fri, 18 Oct 85 17:35:28 -0200
From: Ehud Shapiro <udi%wisdom.bitnet@WISCVM>
Subject: Third ICLP - a reminder
In case you have forgot, or in case you didn't read the Digest
over the summer, the deadline for papers to the Third International
Conference on Logic Programming is December 1st, 1985.
I enclose again the call for papers, since the previos message
suffered from several minor mistakes.
Regards,
-- Ehud Shapiro
P.S. If you have been a referee for the previous Conference or
for the previous Sumposia, please expect to receive a few papers
for refereeing for the winter vacation... We will not ask
explicit permission to send them, but just send them to you and
hope for the best (i.e. for your cooperation...)
CALL FOR PAPERS
Third International Conference on Logic Programming
Imperial College of Science and Technology, London, UK
July 14-18, 1986
In cooperation with:
Association for Computing Machinery
British Computer Society
Japan Society for Software Science and Technology
The conference will consider all aspects of logic programming,
including, but not limited to:
Theory and foundations
Architectures and Implementations
Methodology
Programming Languages and Environments
Applications
Relations to other computation models, programming
languages, and programming methodologies.
Of special interest are papers related to parallel processing,
papers discussing novel applications and applications that address
the unique character of logic programming, and papers which
constitute a contribution to computer science at large.
Papers can be submitted under two categories, short --
up to 2000 words, and long -- up to 6000 words. Submissions will
be considered on the basis of appropriateness, clarity, originality,
significance, and overall quality.
Authors should send eight copies of their manuscript, plus an
extra copy of the abstract, to:
Ehud Shapiro
ICLP Program Chairman
The Weizmann Institute of Science
Rehovot 76100, Israel.
Deadline for submission of papers is December 1, 1985.
Authors will be notified of acceptance or rejection
by February 28, 1986.
Camera ready copies are due April 1st, 1986.
Keith Clark
General Chairman
Imperial College of Science and Technology
180 Queen's Gate
London SW7 2BZ, United Kingdom
Local Arrangements and Exhibition Chairman
Richard Ennals
Imperial College of Science and Technology
180 Queen's Gate
London SW7 2BZ, United Kingdom
Program Committee
Michel van Caneghem, University of Marseille, France
Keith Clark, Imperial College, UK
Veronica Dahl, Simon Fraser University, Canada
Maarten van Emden, University of Waterloo, Canada
Kazuhiro Fuchi, ICOT, Japan
Koichi Furukawa, ICOT, Japan
Ake Hansson, Uppsala University, Sweden
Kenneth M. Kahn, Xerox PARC, USA
Peter Koves, Logicware Inc., Canada
Giorgio Levi, University of Pisa, Italy
John Lloyd, University of Melbourne, Australia
Frank G. McCabe, Imperial College, UK
Jack Minker, Maryland University, USA
Fernando Pereira, SRI International, USA
Antonio Porto, University of Lisbon, Portugal
Ehud Shapiro, Chairman, Weizmann Institute, Israel
------------------------------
Date: Fri, 11-Oct-85 06:11:56 PDT
From: Joe Armstrong <mcvax!enea!erix!joe@Seismo>
Subject: An exciting game in PROLOG
# unpacked will be owned by you and have default permissions.)
#
# This archive contains:
# READ_ME game.pl
echo x - READ_ME
cat > "READ_ME" << '//E*O*F READ_ME//'
A THRILLING GAME IN PROLOG WITH HIGH SPEED HIGH RESOLUTION VT100
GRAPHICS.
This program is donated to the public domain and may be used,
modified re-distributed, or simply throw away as seen fit by the
user.
With this program I hope to fill a 'gap' in the market - I have
often seen requests for "really badly written banal games written
in FORTRAN" - since PROLOG has been described as the FORTRAN of
logic programming I hope this program fills that gap.
I make no apologies for the code, though I suspect that purests
may object to the "(cut,...,fail);true" constructs that are
liberally sprinkled throughout the program.
Plans are underway to write yet more thrilling, exciting,
spectacular, addictive, brilliant, wonderful, enchanting games in
SASL, HOPE, PARLOG, ML, etc.
-- Joe Armstrong.
//E*O*F READ_ME//
echo x - game.pl
cat > "game.pl" << '//E*O*F game.pl//'
/*------------------------------------------------------------*/
/* to run this program: enter prolog and type ['game.pl'],go. */
/*------------------------------------------------------------*/
go :-
noscroll,
system('stty cbreak',_),
start,!,
play.
play :-
putat(24,1,"type space to spin the chamber"),
get0(_),
putat(24,1," "),
random(6,N),
move(24,60),put("you spun "),write(N),
possibly_die(N),
play.
possibly_die(6) :- die.
possibly_die(N).
putat(X,Y,Text) :- move(X,Y),put(Text).
start :-
cls,print_thing_at(2,5,gun),print_thing_at(1,60,head).
die :-
put(7),
print_thing_at(11,20,bang),
un_print_thing_at(11,20,bang),
move_thing_at(2,39,30),
print_thing_at(2,69,bullit),
print_thing_at(11,20,aagh),
un_print_thing_at(11,20,aagh),
un_print_thing_at(1,60,head),
cls,
system('echo "your game got played" | mail joe@erix.UUCP',_),
putat(24,1,"like to dice (sic) with death again (y/n):"),
get0(X),
possibly_doit_again(X).
possibly_doit_again(121) :- start,!,play.
possibly_doit_again(110) :- abort.
move_thing_at(X,Y,N) :-
(for(I,1,N),
Y1 is Y + I -1,
print_thing_at(X,Y1,bullit),
un_print_thing_at(X,Y1,bullit),
fail);true.
un_print_thing_at(X,Y,Z) :- un_print_thing_at_1(X,Y,Z);true.
un_print_thing_at_1(X1,Y,Z) :-
F =.. [Z,N,L],!,
call(F),
X is X1 + N - 1,
move(X,Y),
undraw(L),nl,fail.
undraw(L) :-
(length(L,M),!,for(I,1,M),put(32),fail);true.
print_thing_at(X,Y,Z) :- print_thing_at_1(X,Y,Z);true.
print_thing_at_1(X1,Y,Z) :-
F =.. [Z,N,L],!,
call(F),
X is X1 + N - 1,
move(X,Y),
put(L),nl,fail.
for(I,I,Upper).
for(I,Lower,Upper) :-
Lower < Upper,
Next is Lower + 1,
for(I,Next,Upper).
move(X,Y) :- printf("%c%c%d%c%d%c",[27,91,X,59,Y,72]).
scroll(X,Y) :- printf("%c%c%d%c%d%c",[27,91,X,59,Y,114]),move(24,1).
noscroll :- scroll(1,24).
cls :- printf("%c%c%c%c",[27,91,50,74]).
seed(13).
random(R,N) :-
retract(seed(S)),
N is (S mod R) +1,
NewSeed is (125*S+1) mod 4096,
asserta(seed(NewSeed)),!.
gun(1, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx").
gun(2, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx").
gun(3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx").
gun(4, "xxxxxxxxxxxxxxxxxxxxxxxxx").
gun(5, "xxxxxxxxxxxxx x x").
gun(6, "xxxxxxxxxxxxx x x").
gun(7, "xxxxxxxxxxxxx x x").
gun(8, "xxxxxxxxxxxxxxxxx").
gun(9, "xxxxxxxxxxx").
gun(10,"xxxxxxxxxxx").
gun(11,"xxxxxxx").
gun(12,"xxxxxxx").
gun(13,"xxxxxxx").
gun(14,"xxxxxxx").
gun(15,"xxxxxxx").
gun(16,"xxxxxxx").
head(1, " xxxxxxxxx").
head(2, " xxxxxxxxxxxx").
head(3, " xx xxx").
head(4, " x xxxxxxx").
head(5, " x xxx xxxxxx").
head(6, " x xxxxx x xxx").
head(7, " x xxxx xx xx").
head(8, " x xx x x").
head(9, " x xx x x").
head(10," x x x x").
head(11," x x").
head(12," x x").
head(13,"x x").
head(14,"x x").
head(15,"xxxxx x").
head(16," xx x").
head(17," xxx x").
head(18," xx xxx x").
head(19," xxxx x x").
head(20," x x").
head(21," x x").
bullit(1,"==>").
bullit(2,"===>").
bullit(3,"==>").
bang(1, "xxxx xx x x xxx ").
bang(2, "x x x x xx x x x ").
bang(3, "x x x x x x x x x ").
bang(4, "xxx xxxxxx x x x x ").
bang(5, "x x x x x x x x xxx").
bang(6, "x x x x x xx x x ").
bang(7, "xxxx x x x x xx ").
aagh(1, " xx xx xxx x x").
aagh(2, " x x x x x x x x").
aagh(3, "x x x x x x x x").
aagh(4, "xxxxxx xxxxxx x xxxxxx").
aagh(5, "x x x x x xxx x x").
aagh(6, "x x x x x x x x").
aagh(7, "x x x x xx x x").
//E*O*F game.pl//
exit 0
------------------------------
End of PROLOG Digest
********************