SCOUG-Programming Mailing List Archives

Date:	Mon, 17 Jul 2006 11:01:42 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Clausal versus predicate logic

Content Type: text/plain

First I want to offer you the following:
Software Development Amidst the Whiz of Silver Bullets...
A call to Transylvania may be needed.
http://acmqueue.com/rd.php?c.401
I think you will find it interesting in its assertion that no silver
bullets exist. I really couldn't agree more.

You see I didn't offer a silver bullet, contrary to Greg's
assertion. I simply looked at the difference between
imperative and declarative language use within the SDP as I
"illustrated" in a previous message. I will toggle your memory
by repeating the two basic forms here:

R -> S -> A -> D -> C -> T -> P -> R ... the SDP
M M M M M M M imperative language
M M S S S S M declarative language

Now clearly as both exist, declarative has less manual writing
and rewriting as well as fewer sources to develop and
maintain than does imperative. It's hard in my view to refer to
something as a silver bullet which has been in place and not
used to its fullest extent for over 30 years. Again the success
of SQL lies in part to its declarative nature as well as set
theory which only allows flat "files".

However, SQL will not achieve the completeness shown as it
uses "clausal" logic, which requires that the "test" data be
previously generated. Thus a more correct picture for SQL
would be:
R -> S -> A -> D -> C -> T -> P -> R ... the SDP
M M S S S M M clausal logic, SQL

Now switching to a declarative language which uses predicate
logic alters our visual slightly, but significantly:
R -> S -> A -> D -> C -> T -> P -> R ... the SDP
M M S S S M M clausal logic, SQL
M M S S S S M predicate logic, Trilogy

Now why the difference? It lies in the declaration of the
variables. The declaration requires the specification of the
set of values the variable can have in execution.

I offer you the following example from Trilogy (remember this
was a DOS product made available in 1988). Its manual cover
page has the following statement: "The first ever language to
integrate procedural [imperative], declarative, and database
programming - fast, powerful & easy".

"Some spiders and beetles are in a box. The box contains
forty-six legs. How many spiders and how many beetles are
in the box?"

Let s be the number of spiders and b the number of beetles.
Our basic equation is 8s + 6b = 46. Thus for "all" s and b
integer values where s > 0 & b > 0 find all values of s and b in
which 8s + 6b = 46 is "true". There are two "true" results:

s b
2 5
5 1

Note also that if we had specified 47 that no true results
would have appeared. Thus the need for a "list aggegate"
which can contain 0, 1, or more "true" results.

In Trilogy you specify the range as part of declaring the
variable. However, in truth you don't need the range until just
prior to execution. That says that once you have completed
the completeness proof, the software can provide a list of
variables involved. You can assign a range of values to each
variable. The software will then enumerate the set of all
possible values, submitting each in turn as input to the
process, and produce a list of 0, 1, or more "true" instances.

Note that in the case of our equation where we specify only
that b and s are > 0, we have no upper limit which by default
is plus infinity. If it happened, then Greg's concern that it
would never end has real meaning. Fortunately a "blind"
exhaustive true/false proof doesn't (or shouldn't) occur as
mathematics itself comes to our rescue.

In our equation if we divide 46 by 6 and 8 respectively we get
7 and 5 as upper limits for beetles and spiders respectively.
We know mathematically that "any" higher values would
result in "false". Thus we have no need to go above these
values respectively. We will have exhausted the possible
"true" range. Anything beyond that range produces "false".
We have no need to go there.

Thus we have a means of automatically generating test data
as well as a set of mathematical algorithms we can apply to
optimise (minimize) the amount of test data needed. We can
do this on the set of complete segments (control structures)
for an as yet incomplete program.

As the one-in, one-out rule holds for a control structure,
which is basically a plug-in assembly, the same holds true for
all hierarchical structures of such plug-ins we can iteratively
test them from the lowest level to highest with a minimal
number of generated test data to produce "mathematically"
an exhaustive true/false proof.

So why hope that alpha and beta testers might on their own
generate sufficient test data instances when told, one, you
can possible test all paths of a program, or, two, produce all
possible test data? You enter either alpha or beta testing
knowing its "incomplete" nature. So besides adding additional
"manual" time in the testing stage, in effect delaying the
introduction of the product, why not let the software do what
alpha and beta testers cannot...and need not?

We have an entire industry which justifies its existence on
reducing manual effort in favor of software with the cost and
time savings which we have delivered over and over again.
Now why does this industry resist doing for itself, based on
the same analysis it renders its clients, as it does for others?

When you look at the difference between imperative and
declarative languages, at the division of labor between people
and software, would you not think a declarative C language
retaining its imperative forms better than a strictly C
imperative language? The difference between the two, the
other changes allowing the software to assume responsibility
for the "global" logic, i.e. overall organization, of a program.
Would not something which "frees" the programmer from
rewriting the global procedural logic would amount to a
significant productivity gain?

Now the OS/2/eCS community, decidedly smaller than its major
competitors MAC, Windows, and Linux, has need of an
equalizer. Given its fewer people resources although retaining
highly skilled ones, why would it choose to compete on their
turf on their terms instead of not improving their game plan as
well as their chances for survival?

If they want to continue their brute force imperative
methodology, let them. We have no need to overwhelm our
resources by playing their game. It should be more and more
obvious that they have less and less interest in seeing that we
stay in the game. Look at the SDP. Which options indicate
that we can do more with less? So why would we not pursue
those options...unless we have a death wish?

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 17 | July | 2006 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.