Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Comments of Periera & Shieber wrt Partial Evaluation
Message-ID: <732@cresswell.quintus.UUCP>
Date: 4 Mar 88 10:34:06 GMT
References: <2374@mandrill.CWRU.Edu>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 100
Keywords: Partial Evaluation, Meta-programming, Comments
Summary: y

In article <2374@mandrill.CWRU.Edu>, arun@mandrill (Arun Lakhotia) writes:
> 1. It does not introduce, address or even hint at what partial
>   execution actually means. All P&S have to say is that ``it is a
>   device of general utility for manipulation of Prolog programs. It
>   involves replacing of certain computations that would normally be
>   performed at execution time by changes to the program itself'', 
>   page 98.

Giving some examples and showing what they do doesn't count as
"even hinting"?  "Replacing execution time computations" doesn't
count as introducing or hinting?

> 2. It fails to give adequate references to literature on PE in logic
>   and/or functional programming paradigm.

The book is about natural language processing, not about partial
execution.  There are differences between partial evaluation and
partial execution (classical Horn clause programs do no evaluation:
unfolding code gives you more code, never data).

The question is "what are adequate references"?  In a book whose major
aim is another topic entirely, I contend that "adequate references"
means "enough basic references to get you _started_".

If you would care to supply, say, five key references to partial-
execution-and-logic-programming, I would very much like to have them.

> 4. They consistently use the phrase ``partially execute with respect
>   to X predicate''. It is not consistent with the phrase
>   conventionally used in the PE literature, which is ``partial
>   evaluation with respect to *some data*''. However in the hierarchy
>   of meta and object, the predicates that they `usually' *unfold* are
>   at object level and hence may be interpreted as data for the
>   meta-level.
> 
In (pure) logic programming, a predicate *is* data at any level.
What Pereira & Shieber are in fact doing is building the information
in a predicate into the rest of the program, so the phrase is apt.
It's not an object/meta distinction:  the point is that in the
functional world constants and function applications belong to a
common class, whereas in Horn clause programming terms are terms and
literals are literals.  Even if you supply your data by adding a
goal Var=Term, you have fed in a *literal*.

> 6.  The beauty of PE is in its application as a compiler,
>   compiler-compiler and compiler-compiler generator, as projected by
>   Futamura (1971, 82). P&S, however, fail to do justice to PE by not
>   mentioning anything about these projections, though they give an
>   exercise (Problem 6.14 page 207) to partially execute the partial
>   executor...
>       
"As projected."  "Projections."  Pereira & Sheiber are talking about
*applications*, not *promises*.  Certainly work continues in this
area, and some impressive things are being reported.  But where can
I get one?  

> 8.  Comment on Meta-programming style.
> 
>   P&S require the object program that is to be *interpreted* be
>   available as a set of *clause/1 facts*, page 160-161.  Thus to
>   interpret itself the interpreter should be available as data too.
>   Whether a program interpreting some data, which is *copy* of itself,
>   is self-application may be debateable.
> 
>   I strongly disagree with P&S in their meta-programming style, and
>   prefer that of Bowen, Shapiro, Sterling and others.  The latters use
>   the clause/2 builtin,  which enables referring to program and data in
>   the uniform manner.
> 
>   I cannot understand why P&S did not use clause/2. The closest I can
>   get to is that -- using clause/1 (and program_clause/1) they find a
>   very simple mechanism for stopping the partial execution.
> 
There is a very simple reason for not using clause/2.  In many Prolog
systems (ALS Prolog and Prolog-X are exceptions) clause/2 DOES NOT
APPLY to compiled code, and indeed, in some systems clause/2 only
applies to explicitly designated :- dynamic predicates.  Don't you
think "it wouldn't *work*" is a good reason for not doing it?

The question of whether clause/2 *should* apply to every user-defined
predicate (it obviously isn't going to do much with assembly-coded
primitives) is one question.  Given that it *doesn't* in many Prologs
(including DEC-10 Prolog, for example; and indeed I believe all the
Prolog systems used in the CSLI courses this book was written to go
with) it would have been irresponsible of Pereira & Shieber to tell
their students to use a coding style that wouldn't work.


I begin to understand Ross Overbeek's reaction to my review of
Warren & Maier's book.  I hasten to add that I don't think _their_
references are inadequate for their purpose.

> PS: This note is cross posted to 
>        comp.lang.prolog, 
>        prolog-pe@mandrill.cwru.edu 
>    and pe-forum@hplb.csnet

What are the other two mailing lists?  If there are mailing lists
concerning logic-programming-and-partial-execution, I would like to
be on them, though I haven't anything to contribute.