Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!njin!princeton!phoenix!markv
From: markv@phoenix.Princeton.EDU (Mark T Vandewettering)
Newsgroups: comp.lang.prolog
Subject: Re: Fun. vs. Logic
Message-ID: <11610@phoenix.Princeton.EDU>
Date: 18 Nov 89 18:08:41 GMT
Article-I.D.: phoenix.11610
References: <11500018@hpldola.HP.COM>
Reply-To: markv@phoenix.Princeton.EDU (Mark T Vandewettering)
Organization: Princeton University, NJ
Lines: 93

In article <11500018@hpldola.HP.COM> patch@hpldola.HP.COM (Pat Chkoreff) writes:

>Specifically, I am considering the merits
>of Prolog versus ML or Miranda.

Strictly speaking, I suppose I fall into the functional programming
camp, but I know less of logic programming techniques and
implementation, so take what I say with a grain of salt.  I think I will
play devil's advocate and point out some relatively novel features of 
logic programming languages.

>Most Prolog predicates implement functions, so why not be honest and just
>use a functional language?  It is very difficult, if not impossible, to
>write Prolog relations which work robustly in "all directions", i.e., solve
>for their inputs given their outputs.  

Actually, I am sure this point will be argued by many others, I don't
believe it is that hard.  It may be difficult to make a PROGRAM that is
able to be run in reverse, but individual relations are probably not
that difficult.

Even if it is relatively difficult, it is precisely this ability that
gives logic programming languages an advantage over functional
programming languages.   It is true that if a prolog relation is used
only in a particular mode, it is advantageous to compile it relatively
conventionally.  Mode declarations and abstract interpretation can be
used to good advantage here.  The ability to perform in either mode is a
strong advantage however, because one can query and test facts using the
same set of relations.

>In Prolog, there is a wide divergence between theory and practice, but in a
>functional language, the theory itself is practical.  Most practical Prolog
>programs use constructs which are impossible to define within the pure Horn
>clause model -- they are riddled with constructs such as cut, not, and
>findall, and sometimes even assert and retract.  

There are many purists in the logic programming camp who carefully
rethink the existance of these primitives and try to develop rational
theories for the inclusion, or rational reasons for their abolishment. 
Remember, not all of logic programming is Prolog.

>These detract from the
>value of a Prolog program as a mathematical specification.  The only impure
>constructs I've seen in functional programming are exceptions and
>destructive assignment, and these are very rarely used. 

AIIIGH!  The horror!  ASSIGNMENT?

Exceptions are not necessarily a non-functional construct, it is
relatively simple to design a moderately effective exception handling
mechanism if you adopt a language in which continuations are first
class.  

Destructive assigment is an atrocity, and totally against the spirit of
functional programming, neatly messing up lots of nice properties.  I am
for a language without the crutch of assignment.

>Furthermore, functional programming languages are strongly typed and
>higher-order, which cannot be said for Prolog.  That allows me to do things
>like manipulate graphs as full-fledged objects, rather than as data
>scattered around in extensional relations.  I can do that in pure Prolog,
>too, but it ain't easy.

Functional languages need not be strongly typed, higher order, or
polymorphic (one you missed).  Those are properties of individual
languages in the family.  Again I would stress that there are other
languages than Prolog in the logic programming world.  The reason for
Prolog's popularity among researchers is no doubt because it presents
enough problems that haven't been solved yet :-)

>Are my points mistaken, or are there some features of Prolog which are just
>so wonderful that they eclipse all the bad things?  Maybe logical variables
>or something?  I have quite a bit of experience with Prolog, but none
>whatsoever with ML or Miranda.

Two features of Prolog are particularly outstanding: backtracking, and
logic variables.  

Backtracking allows the simple program of complex control, and promotes
certain kinds of program structures that are cumbersome under
traditional languages, such as "generate-and-test" programs.  

Logic variables allow the instantion of only partially defined data,
without destroying the "pure" nature by having to introduce assignment
to structures to fill in undefined portions of a data object.

Each family have interesting strengths, and provide a rich environment
for future research.  In particular, I believe these two families
provide the most hope for effective parallel implementation.

Till later.

Mark VandeWettering