Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!gem.mps.ohio-state.edu!think!ames!uhccux!munnari.oz.au!mudla!ok
From: ok@mudla.cs.mu.OZ.AU (Richard O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Fun. vs. Logic
Message-ID: <2743@munnari.oz.au>
Date: 18 Nov 89 07:37:34 GMT
References: <11500018@hpldola.HP.COM>
Sender: news@cs.mu.oz.au
Lines: 87

In article <11500018@hpldola.HP.COM>, patch@hpldola.HP.COM (Pat Chkoreff) writes:
> Most Prolog predicates implement functions, so why not be honest and just
> use a functional language?

A function is a relation, so what's dishonest about using a relation?
Don't laugh: but one of the things I like about Prolog is how easy it
is to have a procedure return more than one value without having to
make a special data structure to hold the values and without having
to use special syntax.

There is not one tiny little thing to stop you using functional syntax in
Prolog if you really want to.  Lee Naish and I both have term_expansion
hooks to let you use functional syntax in ordinary Prolog code; mine is
for Quintus/SICStus Prolog, his is for NU Prolog.  With NU Prolog
coroutining behind you, you can generate lazy code if you want.

> It is very difficult, if not impossible, to
> write Prolog relations which work robustly in "all directions".

The simple reason for this is that many predicates have infinitely many
solutions in some directions.  But I fail to see why the fact that a
predicate can't be used ALL ways round is a reason for only letting me
use it ONE way round.  Why not let me use it in all the modes where it
does work?

> The nice thing about a functional language is that the functional
> dependencies are documented within the language, rather than as
> extraneous "modes" or in comments.

So use functional syntax in your Prolog programs.  No-one's stopping you.
I would point out, though, that I have _often_ found that the discipline
of taking something that I initially thought of as a function, trying to
express it in logic, and then asking "is it possible in principle to use
this more than one way around" has led me to a simpler and more general
interface.

> In Prolog, there is a wide divergence between theory and practice

The width of the difference is a good measure of the ability of the
programmer.  Wide gap = bad programmer or bad implementation.

> 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.

The theory is not "pure Horn clauses" but "first-order logic".
In NU Prolog, there are logical versions of not/1 (not/1 *is* the logical
version, as in DEC-10 Prolog and Quintus Prolog; \+ /1 is the unsound one)
and all-solutions predicates, and thanks to indexing, a competent programmer
doesn't need many cuts at all.  And while NU Prolog is not the world's
fastest Prolog system, it's not bad.

> Furthermore, functional programming languages are strongly typed and
> higher-order, which cannot be said for Prolog.

Functional languages do not have to be strongly typed.
Prolog *can* be strongly typed.  My formal specification of Prolog is
a strongly typed Prolog program.  (NU Prolog these days has two type
checkers that I know of.  Lee Naish's one is really amazing.)

Prolog-as-we-know-it is not higher order, but that doesn't stop me using
maplist and such things in Prolog, and there is Lambda Prolog which is a
higher-order logic-based language.

> 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.

Damn right it's easy.  I've done it.

Anything I can do in a functional language I can do in a logic-based language
in roughly the same amount of code.  If I want type-checking, I can have it.
If I want higher-order operations, I can use them.  If I want lazy functions,
I can get that with coroutining.  And I also get reversible code when I take
the trouble to write it, backtracking search when I want it, AND a language
with very strong ties to relational data base theory.

I'm not knocking functional languages:  I have a couple of Schemes here,
I'm a fan of ML from Edinburgh days, I've got and keep rereading Peyton-
Jones, and I'm really impressed with Lazy ML.  But does it have to be
only functional or only logic languages?  Of course not.  Functional and
logic languages both try to be declarative, and they have a lot in common.
One thing which Prolog programmers ought to copy from functional programming
is the determination to stick with the theory as long as possible:  it
really is the case that clean Prolog code tends to be faster than hacky stuff.