[net.lang.prolog] PROLOG Digest V3 #17

RESTIVO@SU-SCORE.ARPA (04/09/85)

From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>


PROLOG Digest            Tuesday, 9 Apr 1985       Volume 3 : Issue 17

Today's Topics:
            Implementations - Searching & C-Prolog & Cuts,
                       & Denotational Semantics
----------------------------------------------------------------------

Date: Sun, 7 Apr 85 18:41:41 pst
From: (Paul Hilfinger) Hilfingr%ucbrenoir@Berkeley
Subject: Searching for best

Suppose that p/1 is defined so that p(X) unifies, in
turn, to all terms in some finite set.  Suppose that
if X is instantiated to a term s.t. p(X), then
cost(X,N) instantiates N to some non-negative integer
cost measure of the term X.  Define the predicate best/1
such that best(X) unifies to all terms such that p(X)
where X has minimal cost.  I'm looking for the most
elegant and efficient general solution that does NOT
use assert, retract, findall, bagof, or things of that
ilk (cut is OK.)  I do have a solution, but I'm sure
that it isn't optimal.

-- Paul Hilfinger

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

Date: 7 Apr 1985 23:10:46 PST
From: Mike Newton <Newton@CIT-20.ARPA>
Subject: C-Prolog on an IBM

About 10 (?) issues ago i sent in an article describing
the changes to  C-Prolog 1.5 to get it running on an IBM
mainframe.   Anybody that has done this change is requested
to run  the following Prolog 'programs':

?-  4.1 < 2.

?-  4 + 7 < 2.

If either cause a problem, send me a note for a long (~ two
page) fix.

[This bug only shows up as a result of some C compilers.]

-- Mike

Caltech 256-80
Pasadena CA   91125
818 356 6771

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

Date: Fri, 5 Apr 85 17:21 EST
From: Mark Beutnagel <Beutnagel%upenn.csnet@csnet-relay.arpa>
Subject: Another C-Prolog Port

I have ported CProlog v1.5.EdCAAD from VAX to a M68000
based HP workstation,the HP 9000 Series 200.  It is running
under HP-UX v2.1, which is basically System III Unix plus
extras from 4.1 and 4.2 BSD.

Only minor changes were required, mainly in the makefile
and in parms.c, to use the correct #defines and startup
file.  A record of these changes can be made available to
interested parties.

All seems to be running well with the exception of the
following message from the save predicate: "Not a
typewriter".  In spite of this and [execution aborted]
from Prolog, the reloaded files work (so far).

Apparently save tries to do some terminal IO to the file
and Unix objects, but I haven't found the culprit code yet.

If anyone has seen or fixed this problem, suggestions
would be gratefully recieved.

Regarding Mike Newton's bug:

[ f(Y) :- (true,! ; X=0),Y=<7. ]

this version exhibits no symptoms even though pl/init uses

$call rather than
$hidden_call to define (A;B).

-- Mark Beutnagel

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

Date: 3 Apr 85 01:19:37 GMT
From: (David Powers)decvax!mulga!elecvax.oz!DavidP@Berkeley
Subject: "soft" cuts

Coming in on a response to a query I missed concerning
"soft" cuts:

I added such a construct to UNSW PROLOG in 1982 - it is
a very simple change, related closely to traditional cut.
I used the symbol "#", hash, and the term "half cut".
An example of its use compared with alternative ways of
achieving the same end is given in Chapter 5, pp19-28 of

UNSW DCS Technical Report 8313, D.M.W.Powers and G.B.McMahon,
"A Compendium of Interesting PROLOG programs" (December 1983).

The advantage of half cut is that it allows obtaining all
solutions, if any exist, and execution of an alternative
strategy or error routine otherwise.  I have not found any
markedly different application.  My original application
was natural language parsing/learning.

This half cut cannot be simulated with Horn + cut
(without assert/bagof/...), but the other half - commit to
current track within clause but not to current clause -
can be simulated with cut alone.

I am happy to look out the specific mods to UNSW PROLOG for
those who request them.

-- David M. W. Powers

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

Date: Mon 8 Apr 85 19:33:03-MST
From: Uday Reddy <U-REDDY@UTAH-20.ARPA>
Subject: Logic Programming Semantics

I agree with Joseph Goguen in principle.  But, I think
his proposal is a bit too idealistic.

First of all, my notion of denotation semantics is very
broad.  I would consider any specification of semantics
that is (1) compositional and (2) complete to be
denotational semantics.  It does'nt have to be written
in the Oxford style, or deal with infinite structures.
Denotations don't also have to be functions.  Functions
just turn out to be the most convenient denotations most
of the time.

When Josephs says "the good thing about a real logic
programming language is exactly that it does not need
such a [denotational] semantics", I take it to mean that
we already know its denotational semantics.  Well, this
does not hold most of the time.  For instance, pure Horn
clauses don't satisfy this, as they work in the
{true, unsepcified} domain as opposed to the good old
logic we know, which works in a {true, false} domain.
Are Horn clauses then "well understood"?

I see nothing wrong with Pure Prolog, for instance,
which uses sequential "and" and "or" operations in a
3-point {true, unspecified, fail} domain.  Even though
its semantics may not have been "well understood" in
classical logic, the pragmatics of computing make it
necessary and it is simple enough.

Pragmatics of computing require us to move away from or
add to what we import from other disciplines such as
logic or mathematics.  This is not necessarily wrong.  I
can't see anything other than the subjective notion of
"simplicity" to guide us in deciding what is good or
bad.

Pragmatics of computing is also what makes languages
which work in initial models (the models which precisely
describe the inferrable equality) impractical.  Testing
for equality of two terms t and u requires m.n
comparisons where m and n are the number of reduction
steps for t and u respectively.  On the other hand,
continuous equality in the least model (which is what is
used in functional languages) requires only 1
comparison.  So, if continuity requires learning a good
amount of computer science's own (not logicians')
theory, it is certainly worth it.

The dangerous attitude in logic programming community is
the step-motherly treatment given to "control".  As if
control does not affect the meanings of programs or as
if we don't need to understand it.  This is what I am
objecting to.  Suppose someone said FORTRAN was a
language of well understood arithmetic expressions.
Everything else in it was just "control"!

-- Uday Reddy

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

End of PROLOG Digest
********************