Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!newsgate.duke.edu!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!allegra!alice!pereira-x.research.att.com!user
From: pereira@research.att.com (Fernando Pereira)
Subject: Re: Language ecology (was: Is Visual Prolog "real" Prolog?)
X-Nntp-Posting-Host: pereira-x.research.att.com
Message-ID: <pereira-2005960041480001@pereira-x.research.att.com>
Sender: usenet@research.att.com (netnews <9149-80593> 0112740)
Organization: AT&T Research
References: <317752DA.C2C@pdc.dk> <andrews.830314122@Turing.Stanford.EDU> <4m4ard$knq@goanna.cs.rmit.edu.au> <4mda7n$7mk@mod-serv.dfki.uni-sb.de> <4mn8jk$pje@mulga.cs.mu.OZ.AU> <pereira-0805962321250001@greeley.research.att.com> <4nilp3$qd5@orion.cybercom.net> <4nj74a$jta@soap.news.pipex.net> <pereira-1805962140010001@pereira-x.research.att.com> <4nnvln$7vr@soap.news.pipex.net>
Date: Sun, 19 May 1996 23:41:48 GMT
Lines: 49

In article <4nnvln$7vr@soap.news.pipex.net>, John Fletcher
<lk04@dial.pipex.com> wrote:
> [...]
> I think you're reading a lot into this, I don't believe  that forall/2 is
> tied to the underlying machine any more than findall/3 is.
I disagree strongly. Since forall/2 does not produce a result but just
success or failure, you are forced to put a side-effect in its second
argument. The sequence of side effects generated by that call to forall/2
is specified by the underlying machine (backtracking). In contrast,
findall/3 does not (or need not -- cf. its improved cousin setof/3)
require that kind of knowledge of the underlying machine to be used. The
order of the result list is dependent on the machine, of course, but
proper use of findall/3 does not depend on the order of the list.
> I agree that we would like the definition of the program to follow a 
> natural language specification closely, but that specification might be: 
> "Print the report title then print the name of each person". 
That English specification is already contaminated by imperativism. Unless
we are instructing someone to do something step by step because we don't
believe they can fulfill correctly a higher-level request, we don't speak
that way. We describe the result sought, not how to accomplish it.
> [...]
> I suppose this all illustrates the importance of showing how Prolog can be 
> exploited practically, as well as "ideally". Your program shows that even
> the use of imperative side-effects doesn't have to be kludged and can be
> layered so that it doesn't dominate the structure of the program. I wonder
> how many introductory courses even touch on this sort of thing...
Not that many, I'm afraid. But the problem is not just with Prolog texts,
one sees example programs with I/O spread all over the leaves of the call
tree in textbooks for all sorts of languages. Not only does this style
undermine modularity --- the meaning of a subprogram is now some awful
combination of argument/result relation and side-effects --- but it is
also impractical in event-driven situations (eg. interactive editors), in
which interaction with the outside is near the root of the call tree, not
near the leaves. As far as the standard argument that separating I/O from
computation forces the program to remember more and is thus less efficient
I prefer to build it right and *then* change it for efficiency if
necessary, after finding efficiency bottlenecks. Furthermore, there are
general ways of thinking about interleaving the computations of multiple
modules, either by using concurrent languages or by using "deforestation"
techniques. The typical deforestation example is sameleaves/2, which
checks if two trees have identical lists of leaves. The naive definition
is

   sameleaves(T1, T2) :-
      leaves(T1, L),
      leaves(T2, L).

Exercise: eliminate the intermediate list L. Similar reasoning can be used
to combine I/O with computation if efficiency demands it.
