Re: Discussion: Is prolog domain specific?

From: robert (gnuoytr_at_rcn.com)
Date: 06/09/04 

Date: 9 Jun 2004 06:11:19 -0700

bart demoen <bmd@cs.kuleuven.ac.be> wrote in message news:<1086721820.789396@seven.kulnet.kuleuven.ac.be>...
> robert wrote:
>
> > 1) prolog semantics require exhaustive search. this is never efficient,
>
> Not true. The availability of exhaustive search lets you program things
> you do not (yet) know any other algorithm for.

this cannot be the basis for a general purpose programming language. the
OP's question was cast as

    Its capability for solving problems is so general

its capabaility is far from general; it is terribly narrow. as you just
said.

Whether locally
> exhaustive or globally exhaustive, it's just a plain fact of life that
> it comes in handy often - and often the issue is not whether it is
> efficient, but whether you can do it at all.
>
>
>
> > as is, it's just not scalable.
>
> Some problems are just not scalable

again, a cry for narrowness, not generality. the computational method
matters in deciding the problem scope a language can address.

- and then exhaustive search can
> make as much sense as any other method. And if you have an easy, scalable
> problem, a good Prolog programmer will be able to write a scalable
> solution for it in Prolog.
>
>
> > there may
> > be products well integrated with relational databases which do
> > better.
>
>
> "products well integrated with relational databases" ... most Prolog
> systems come to mind - integration with SyBase, Unify, Oracle ... the
> integration is named a deductive database - exists since the mid 80ies
> (at least)

integrated in the sense that there is NO in-memory database of facts.

>
>
> > 2) to get around 1), most implementations provide cut(!),
>
> No, no ! A system without cut(!) simply isn't Prolog !
> It can be ressemblant in syntax and other things, but without cut,
> it is something different - ask Mercury people :-)

argue with S&S, pg. 189: "The use of cut is controversial. Many of
 its uses can only be interpreted procedurally, in contrast to the
 declarative style of programming we encourage."

>
>
> > but, you no longer have a declarative language.
>
> Prolog wasn't a fully declarative language to start with. It has some
> declarative features, and you can write declarative programs in it,
> but as a language, it is not fully declarative.
>
>
> > and, you have to do the ! just right, or you end up with
> > a mess (and never get an error).
>
> Name us one language with no feature that you (as a programmer) can do
> not just right and if you do, you do not end up in a mess and you
> get errors.

the point is, no error at compile or run time. in an imperative
language, since the algorithm is known, results can be tested. this is
much more difficult in prolog, where the only option is for the
user to conduct the exhaustive search manually. on toy problems, this
will work. for industrial strength applications, it is not.

>
>
> \begin{opinion}
> > 3) the syntax is bizzare.
> \end{opinion}

 <widely held opinion in the language community/>
>
>
> > variables are just manifest constants.
>
> ???

variable which cannot be changed are not variables, they are
constants. constants which are named are manifest constants.

>
> > symbols with established meaning in the world of languages take
> > on unrelated meanings.
>
> examples please ! Or are you just mud throwing ?

<=>, !, [], |, =:= (== ??),
>
>
> > 4) unification functions by its side effects.
>
> I beg you pardon ... unification is perhaps one of the few things in
> Prolog that have no side-effects

S&S, pg. 125: "Unification subsumes
               - Single assignment
               - Parameter passing
               - Record allocation
               - Read/write-once field-access in records."

which ONE of these is the effect? if they can all happen all the time,
which ONE is the effect. in simple <=> the text, nor compiler
can tell whether the left is assigning to right or the other way round.

- or maybe you have a different notion
> of side-effect than me - so, please explain: what is the side-effect
> in unification ?
>
>
> > 5) while allegedly declarative, predicates are executed procedurally;
> > order of execution matters.
>
> Please tell us how a predicate can be executed declaratively.

that's your job, as defender of the language. i'm merely pointing out
that the language is inconsistent in its syntax/semantics.
>
>
> > both the syntax and semantics lack consistency.
>
> What do you mean by an inconsistent syntax ?
> Or did you use the word "consistent" as in "a consistent meal" ?

it mixes in imperative and procedural constructs with declarative
constructs.
>
>
>
> > 6) it pattern matches. awk and perl do that too.
>
> And so does Haskell - another "declarative" language.

Haskell is viewed as functional. i don't recall it being called
declarative.

> Prolog "unifies" - that's strictly more than pattern matching -
> non-logic-bases languages (perl, awk, Hsakell ...) don't.
>
>
> > 7) backtracking, often proposed as a strength of the language: "In a
> > conventional language, if a computation cannot proceed (e.g., all
> > branches of a case statement are false), a runtime error occurs. In
> > Prolog, the computation is simply undone to the last choice point
> > made, and a different computation path is attempted." (The Art...
> > pg. 125).
> > well, not really. the notion of computational failure is just not
> > the same between imperative and declarative languages. this is a
> > straw man, and leads to the problems of 1) and 2).
>
> Not at all. As I have advocated before: "backtracking is your best
> friend: it never fails you". Backtracking is really one of the strengths
> of Prolog. Many people argue it is insufficient, crude, doesn't always
> scale (and I agree) but it is one of the things that makes Prolog stand
> out against other languages: one can program things without knowing the
> deterministic algorithm and still get an answer.

but how do we know the answer is correct? because we affirm that the
facts and rules are right.

The closest one can get
> to that is programming in non-deterministic Turing machines - not an
> attractive alternative, is it ?
>
> > python or eiffel are not COBOL, BASIC, or C; thus having "different"
> > cache', but also a greater degree of usefulness.
>
> (you mean "niche" instead of "cache" ?)

i mean cache'. as in "I summer in Nice". "I code Eiffel".

> Please define "degree of usefulness".

being useful as a general programming language. whatever happened to
that fifth generation project, anyway??

robert
>
>
> Cheers
>
> Bart Demoen

Relevant Pages

  • Re: Minsky still posting
    ... |>> I think the relatively simple control mechanism of Prolog is the ... |> The programming "market" obviously doesn't select tools on technical ... | a structured assembly language, and I use Java as a practical language ... | languages that academics have put so much work into - the functional ...
    (comp.lang.prolog)
  • Re: Sublists question
    ... I do not really get what the predicate means or does. ... >>helps just to write the predicate out clearly in natural language, ... >>then translate into Prolog. ... more as a functional programming language than as a logic ...
    (comp.lang.prolog)
  • Re: Real World Applications
    ... For Prolog `in the wild', that may be true, I see a lot of really ugly ... As long as people follow shared design ... I don't think that is a real issue with the language. ... graduate courses in logic and logic programming. ...
    (comp.lang.prolog)
  • Re: Mainstreaming Prolog a Pragmatic Approach?
    ... experience is that Prolog is an incredibly useful language for virtually all ... often than not end up using Prolog. ... I think you're right when you question whether logic programming really ...
    (comp.lang.prolog)
  • Re: Discussion: Is prolog domain specific?
    ... Some problems are just not scalable - and then exhaustive search can ... solution for it in Prolog. ... Prolog wasn't a fully declarative language to start with. ... deterministic algorithm and still get an answer. ...
    (comp.lang.prolog)