🚀 go-pugleaf

Is it my imagination, or did Pat Chkoreff thrash through a
remarkably similar discussion on fun. vs. logic a couple of
years ago, on comp.ai or something?

In article <11500019@hpldola.HP.COM> patch@hpldola.HP.COM (Pat Chkoreff) writes:
>....  But here's what ticks me off about Prolog:
>the danger of NON-TERMINATION is constantly rearing its ugly head.

     You mean it isn't in functional languages?

>  I write
>a predicate, and then I immediately see how it is riddled with dangers when
>I call it in certain ways.  I'm not even talking about dangers due to the
>lack of the occurs check:  there's not a thing I can do about those.

     As far as I can tell, what you're saying is that the Prolog
interpreter is difficult to understand, ie. that its operational
semantics is more complicated than that of functional languages.
I think we knew that already.  We also know that its declarative
semantics makes it a much more appropriate language for *certain*
problems than any functional language.

>I can either document these dangers in comments, mode declarations, or some
>other "bag" on the side of the language,...

     Comments are a "bag" on the side of a language?

>....  I suspect that these representations have a
>lot in common with what is known as "constructive mathematics".

     Bing!  Five points for Pat.  The crowd goes wild.

>But how do you determine the modes in which it works, how do you document
>them in the language, and what does it mean to the compiler?  What would you
>end up with?  A sort of hybrid functional/logic language?  GREAT!  I'd fill
>out a purchase request for that.

     Double great!  Send it to:

     Complete Logic Systems, Inc.
     741 Blueridge Ave.
     North Vancouver, BC
     Canada   V7R 2J5

     Ask for a copy of Trilogy.

>By the way, I'll bet that a lot of predicates which SEEM to have infinitely
>many solutions in some directions can be recast so that they don't.  The
>problem is:  it's a major pain in the ass.
>Here's an example....

     Hmm.  So when a logic programmer encounters difficulties
like this, he or she writes papers in conferences about them and
how to solve them.  When a functional programmer encounters
difficulties like this, he or she throws up his or her hands and
goes back to Interlisp.  (No problems there!)  I guess that's
the real difference between funs. and logic?

>Besides, what is "first-order logic" other than Horn clauses?  (That's not a
>rhetorical question.)

     Yet another example of the shocking absence of logic from
our undergrad curricula.

>...  But "commitment" is
>fundamentally syntactic sugar, whereas "cuts" are not.  You could replace
>"cuts" with negated conjunctions, but how do you define negation?  In terms
>of cuts, most likely.

     Wow!  Cuts and negation cause semantic problems!  Another
five points for Pat.

>Now pure Prolog is a slick little language, too.  But then you add cuts,
>negation, and findall.  And then you add type checkers and mode
>declarations.  And then you invent extended languages.  You stick all these
>"bags" on the side of Prolog, and the result just doesn't cohere as well as
>I'd like.

     Boy, sounds a lot like Interlisp, eh?

--

     Well, enough of this; I've obviously been reading too much
alt.flame for my own good!  The serious point I want to make is
that logic progamming languages often have serious problems,
many of which Pat has pointed out.  But we shouldn't judge the
logic programming paradigm by the performance of given systems,
or assume that LP researchers are blind to the problems and
don't care about solving them.  Trilogy is only one of a number
of examples of logic programming languages which try to address
such problems as irreversability of predicates and the need for
functional notation.  (Standard disclaimer:  Trilogy was
developed by my M.Sc. advisor, Paul Voda, and I wrote the user
manual, so I'm a little biased.)

     Functional languages have their problems too.  I used the
example of Interlisp above, which was about the most extreme
example I could think of -- an ad hoc assembler-cum-operating-
system masquerading as a functional programming language.  That
was a good many years ago now, and languages like Scheme and ML
have come along since then.  The logic programming paradigm is
more complex, and has been around for a shorter time, so I don't
think we can expect beautiful things like ML to come out of it
for a while yet.

     But ML has problems too.  The type system is just too rigid
for some people's taste.  The absence of EVAL (due to its
non-typability) means that certain programming techniques are
out.  Whatever your distaste for destructive assignment, every
programmer writing serious large applications will tell you that
it's often an absolute necessity; ML has it but doesn't give
it a dynamic semantics.  (Trilogy, on the other hand, has it and
accounts for it fully.)  And, more to the point of this
discussion, you can't program search for solutions, and stay as
true to the logical structure of the problem, as well as you can
in logic programming languages.

     So the summary of the summary is that all languages have
problems; if there was one that didn't, everyone would use that
one.  You can reel off a litany of problems with a language or a
class of languages, but the response should be ``let's integrate
things and try to make everything work better'' rather than
``my paradigm is better than yours.''

     My apologies if any of the flaming above caused serious
offense.  :-)

--Jamie.
  jha@lfcs.ed.ac.uk
"The sun and the moon, the wind and the rain"