                                                                                                                                                                                                                                                                
Path: g2news1.google.com!news4.google.com!out01a.usenetserver.com!news.usenetserver.com!in04.usenetserver.com!news.usenetserver.com!in01.usenetserver.com!news.usenetserver.com!news-xfer.nntp.sonic.net!posts.news.sonic.net!nnrp0.nntp.sonic.net!not-for-mail
Message-ID: <465D0129.6070307@nowhere.net>
Date: Tue, 29 May 2007 21:44:25 -0700
From: student <no-s...@nowhere.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
MIME-Version: 1.0
Newsgroups: comp.lang.prolog
To: Duncan Patton <campb...@neotext.ca>
Subject: Re: Business Rules in Prolog
References: <1178437917.247473.164730@h2g2000hsg.googlegroups.com>	<464112e3$0$27172$742ec2ed@news.sonic.net>	<6h8243tsv84u244sj5ucsvllvk91gusa6f@4ax.com>	<464195cf$0$14125$742ec2ed@news.sonic.net>	<4641a108$0$321$e4fe514c@news.xs4all.nl>	<4644566b$0$14140$742ec2ed@news.sonic.net>	<4644597c$0$338$e4fe514c@news.xs4all.nl>	<464568ba$0$14107$742ec2ed@news.sonic.net>	<cnbb4359crom48fmqoj74bu2ns0gce3vhp@4ax.com> <20070512134141.4a0dc66a.campbell@neotext.ca>
In-Reply-To: <20070512134141.4a0dc66a.campbell@neotext.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 164
Organization: Sonic.Net
NNTP-Posting-Date: 30 May 2007 04:41:37 GMT
NNTP-Posting-Host: c3a5bc26.news.sonic.net
X-Trace: DXC=K0m869?C?EO2=j=_j0aTIJm4K\QM1CV^@1OYf0H`?;XAnn49d<Oe\>DcnSlmYfATSMb9d4jd9T`ZG=\J3W1O[>WL
X-Complaints-To: abuse@sonic.net

Duncan Patton wrote:
> 
> It is my understanding that all computationally complete languages
> are inter-"translatable".   
> 
> Dhu
> 
> 

   With all due respect, Mr Patton, that is not the issue.

   I happen not to believe that any version of "Prolog" that does not
require the domains of all user-defined predicates to be defined
in advance should even be taught in school, much less be used to 
implement a real-world application that will have to be maintained in an 
environment that is subject to sudden and unanticipated changes and in 
which software defects translate into the risk of dangerous or costly 
mishaps.

   The reason I feel this way is very simple: the number of different
ways it is possible to map the "slots" of a rule that has n "slots" to
Prolog variable names is B(n), where B(n) is the number of different
ways it is possible to partition a non-empty set of size n.

       B(n) increases rapidly in n.

       n           B(n)
       2           2
       4           15
       6           203
       8           4,140
       10          115,975
       12          4,213,597
       14          190,899,322
       16          10,480,142,147
       18          682,076,806,159

   However, when the individuals that comprise the domains
referenced in a rule are fundamentally different sorts of things, the 
*proportion* of these different mappings that make sense in material 
terms diminishes rapidly as n increases.

   For example, consider a rule of the form

       p(_,_) :- q(_,_), r(_,_).
         1 2       3 4     5 6

This rule has 6 "slots", numbered from left to right.

   Suppose now I fill in these slots with variable names as follows:

             p(A,B) :- q(A,T), r(T,B).

This way of mapping the slots in this rule to Prolog variables 
corresponds to partitioning the 6 slots as follows:

             { {1,3}, {2,6}, {4,5} }

   But there are 202 other ways these same 6 slots can be mapped to 
variable names, so if in fact the rule

             p(A,B) :- q(A,T), r(T,B).

correctly distinguishes three domains and these three domains are in
reality as different as (say) geese, wine, and cheese, then only the
following 7 of the other 202 mappings make sense in real terms:

****************************************************
declaring sorts [[2,6],[4,5],[1,3]]
allows the following mappings of slots to variables:
----------------------------------------------------
[[2,6],[4,5],[1,3]]
-------------------
[[2,6],[4,5],[3],[1]]
[[6],[4,5],[1,3],[2]]
[[6],[4,5],[3],[2],[1]]
[[2,6],[5],[4],[1,3]]
[[2,6],[5],[4],[3],[1]]
[[6],[5],[4],[1,3],[2]]
[[6],[5],[4],[3],[2],[1]]
----------------------------------------------------
total number of allowed mappings: 8
****************************************************

   For example, if we label the three domains as

     { !geese={1,3}, !wine={2,6} , !cheese={4,5} }

then the rule

     p(Goose,Wine) :- q(Goose,U),r(V,Wine)

i.e.,

     p(Goose,Wine) :- q(Goose,_),r(_,Wine)

-- which instantiates the partitioning { {2,6}, {5}, {4}, {1,3} } -- 
makes material sense and may very well have been intended.

   But the other 195 ways of mapping the 6 slots in this rule to 
variables names simply make no sense whatsoever in real terms.

   For example, the rule

     p(Goose,Goose) :- q(Goose,Wine), r(Wine,Wine).

by instantiating the partitioning { {1,2,3}, {4,5,6} ) speaks of a wine 
that is at the same time both a goose and a cheese, something which is 
as difficult to visualize as it is unlikely to have been intended.

   In fact, the only conceivable purpose in writing such a rule would be
to detect the presence of precisely the kind of database errors that a
properly designed system of type definitions and "slot" mapping
specifications eliminates altogether.

   [Please note that the matter of distinguishing domains that are, or 
are required to be, mutually exclusive in the real world is completely 
orthogonal to the matter of the "type" (form) of the (ground) Prolog 
terms that we use to distinguish individuals within those domains. To 
anyone who is not colorblind, it is easy to visualize the difference 
between a red "3" and a green "3". Conversely, limiting a Prolog 
programmer to using a handful of predefined *types* to distinguish 
*domains* would be like forbidding a child to combine different crayons 
from the same box by "coloring over".]

   The point is that mistakes of this kind are very easy to make and
because there are so many different possible ways of making them, we all
make them all the time. Thus, in the absence of any way to detect such
errors of this kind at compile-time, the probability that one or more of 
them will sneak into a large Prolog during its development is virtually 
certain. (Who was it said testing can prove the presence of bugs but not 
their absence?)

   Unfortunately, once such a error creeps into a software system, its
presence may not even be suspected until serious system dysfunction
occurs -- in which event the difficulty of finding it will greatly
complicate the problem of deciding whether the observed system
dysfunction  stemmed from the incorrect implementation of a correct
design specification or from the correct implementation of an incorrect
design specification; conversely, if the presence of such mistakes can
be ruled out categorically, that problem is greatly facilitated.

   Non-sorted, non-typed ISO-style Prolog systems largely ignore this 
issue and by so doing misrepresent the representation problem (a.k.a. 
the writing process). As I have said many times before, requiring a 
young person to use a non-sorted, non-typed ISO-style Prolog to 
construct a description from which answers to questions about its 
subject can be deduced formally is like being required to wear iron 
boots when you are just starting to learn how to swim,

   The plight of any software engineer who is required or who feels 
compelled to implement a complicated control system using a non-sorted, 
non-typed ISO-style version of Prolog will be no different. He'll have 
to kick a lot harder and he'd better stay out of deep water.

   Greetings,
   billh

w d b h at s o n i c dot n e t

-- 
-- billh

  Truth is a tiger with many tails.
