Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!mulga!lee
From: lee@mulga.oz (Lee Naish)
Newsgroups: comp.lang.prolog
Subject: Re: Badness
Message-ID: <2385@mulga.oz>
Date: Mon, 9-Nov-87 21:22:49 EST
Article-I.D.: mulga.2385
Posted: Mon Nov  9 21:22:49 1987
Date-Received: Thu, 12-Nov-87 06:43:58 EST
References: <8711090842.AA20806@ucbvax.Berkeley.EDU>
Reply-To: lee@mulga.UUCP (Lee Naish)
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 38

>From: blenko@burdvax.PRC.Unisys.COM (Tom Blenko)
>Subject: Badness
>
>My favorite bit of erroneous Prolog software is the oft-cited append()
>procedure/relation:
>
>        append([],X,X).
>        append([H|T1],X,[H|T2]) :-
>                append(T1,X,T2).
>
>I don't believe I've ever seen the incorrectness (by Richard's view)
>acknowledged in a text or publication,

I discuss it in "Specification = Program + Types".
I argue that in the *natural* specification for append, all arguments
must be lists.  The paper introduces the notion of "type correct"
programs (which can include the normal version of append) and shows
why these programs do not produce well typed but incorrect answers.
The Mycroft/O'Keefe type checker can also be used to catch programs
which call append with non-lists (both these refs have been posted
recently).

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

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

	Lee Naish