SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 4 Jan 2004 17:27:10 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Gregory Smith writes:
"Replace the word "specification" in what I wrote with as
much PL/I syntax as you want. I think my point still holds.
It is not a case of "belief" in SQL. It is a byproduct of
my background that SOME things HAVE to be done in order. ..."

:-)

Greg,

I can appreciate when something upsets you. When it comes
as in your response I think you're at your best upset.
However, get upset over a real issue, not one on which you
and I both agree.

No disagrees that some things have to be done in order. No
one can argue that in software we don't have an explicit
order. The issue lies in how we have to come to that order.

The completeness proof in logic programming imposes an
optimal order on unordered input. It does that because it
follows the same rules you would in imposing an optimal order
on the same input. If you have encoded the rules, there's
little sense in you through writing establishing the order when
the software can do it for you faster and cheaper. There's
little sense when a change in the input requires a change in
the order for you to do the reordering when the software can
do it for you faster and cheaper. In either case it saves you
time, i.e. increases your productivity. It allows you to achieve
more in the same time or to achieve the same in less time.
Unless you have concerns about what you are going to do
with the time (and effort) saved, you ought to take
advantage of it.

You have to impose a certain order where physical equals
logical on some processes. This must precede that. In
software we do this in a control structure called a sequence.
However, it relates only to that segment of code in which the
order must occur. That same order occurs in a case
statement, e.g. "select (...); when ... end; when ... end;
otherwise ... end; end; /* select */, where the order in which
the tests occur is important.

Here you have a specification assembly, a code segment of
two or more statements in which the order is important. The
completeness proof will do nothing to change that internal
ordering any more than it has the ability to determine that
order.

One of the difficulties I have with the Prolog syntax lies in its
manner of stating ordering of source which must be
maintained. They do it by connecting each individual
statement with an "and" represented in Prolog by a comma.
As the "and" in logic is commutative, meaning the order is
unimportant, this convention is at best confusing, at worst a
clear violation of the formal logic on which it rests.

In SL/I, for example, we write the specification assembly, i.e.
the ordered code segment, in the normal manner of
terminating each statement with a semi-colon, marking the
beginning and end with either "begin;...end;" in the instance of
a sequence and "select (...);...end;" in the instance of a case
control structure, and giving a label, a name, to the code
segment. References in the remaining source to these
segments occurs by name only. These source references
offer an option of executing the named ordered segment
either in-line or out-of-line.

I had thought in an earlier response in a different thread I had
covered that reuse occurred at the statement level on up
through code segments representing control structures to
code segments representing assemblies of control structures
up to the procedure or API level. The order within any
assembly is maintained throughout. It is only the order
outside these assemblies imposed upon them as a group that
the completeness proof performs.

I hope this puts to rest all doubts you may have about how
necessary order is maintained in logic programming. In the
example of SQL we should mention that a similar and
necessary order is imposed in implementing nested queries.
However unordered the columns, tables, and conditions may
be within each query, the order, the sequence of execution,
of the queries themselves is fixed.

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

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
"rollin@scoug.com".

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

Return to [ 04 | January | 2004 ]

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.