Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!princeton!udel!burdvax!blenko
From: blenko@burdvax.PRC.Unisys.COM (Tom Blenko)
Newsgroups: comp.lang.prolog
Subject: Re: Badness
Message-ID: <4815@burdvax.PRC.Unisys.COM>
Date: Tue, 10-Nov-87 19:27:31 EST
Article-I.D.: burdvax.4815
Posted: Tue Nov 10 19:27:31 1987
Date-Received: Fri, 13-Nov-87 05:11:37 EST
References: <8711090842.AA20806@ucbvax.Berkeley.EDU> <2385@mulga.oz>
Sender: news@burdvax.PRC.Unisys.COM
Organization: Unisys Corporation, Paoli Research Center; Paoli, PA
Lines: 47

In article <2385@mulga.oz> lee@mulga.UUCP (Lee Naish) writes:
|>From: blenko@burdvax.PRC.Unisys.COM (Tom Blenko)
|>Subject: Badness
|>
| ...
|
|>        3. Backtracking and cut are more difficult use than more
|>           conventional control constructs
|You may be right about cut, but if you program declaratively,
|backtracking is never a problem.

But it isn't clear what the admonition to program declaratively means.
Programming declaratively, in the sense of pure PROLOG (without call(),
not(), and cut()) is not even powerful enough to express IF-THEN-ELSE,
which I am willing to assume is a _sine_qua_non_ for programming.  One
can get IF-THEN-ELSE back with call() and not(), but the
non-declarative character of PROLOG not() is also well known.  So I
don't think we can take "program declaratively" too seriously if it
means that we cannot express IF-THEN-ELSE (because it doesn't suffice
as programming), or if it means that we have to admit call() and not()
(because then it isn't declarative).

Just to save some time here, I also point out that not() restricted to,
or delayed to await, grounded arguments, as you and others have
proposed, does not get one out of the difficulty (of expressing
IF-THEN-ELSE declaratively when the condition requires more than
constructor matching).

|
|>        5. It is well known that O'Keefe's and Naish's exhortations
|>           to Lagache (for sensitivity to efficiencies in the
|>           implementation and for conformity to simple declarative
|>           interpretations) will sometimes conflict.
|It seems less well known that more often they do not conflict!
|You should always look for a clean solution first.  After that, you can
|try to "optimize" it by adding cuts, asserts etc.  Often you find it is
|not necessary and/or makes the program *slower* (ask Richard about this
|if you like).

I'm not sure we're disagreeing. I do recall a perfectly fine
declarative program for append3() that you cite in a paper as suffering
from non-termination, even though correct declarative solutions are
also possible, and other examples are not too hard to come by.  So I
think the "program declaratively" admonition is not even safe,
efficiency questions aside.

	Tom