SCOUG-Programming Mailing List Archives

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

Date:	Thu, 7 Aug 2003 07:34:27 PDT7
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: Re: Warpstock 2003 Presentation

Content Type: text/plain

Steven Levine writes:
"Hey, it's just bog standard SQL which you said was based on
logic programming. I'd have to check, but I don't even think
there are any Informix specific extensions in this snippet. ..."

I get up this morning to see that you people stayed up a little
longer enjoying yourselves. I quess here we have a difference
about what is "standard" SQL and what is not.

I can be more specific about my logic programming reference
within the body of an SQL statement of the form "select ....
from ... where...". Here the user states the conditions, what he
wants, leaving it to the processing to determine how to do it.
The completeness proof verifies against the system
maintained descriptor tables that the user has provided
sufficient and correct data (names and conditional logic). If
he hasn't the system will return a "false" condition denoting a
specific error. Otherwise it returns a "true", moving
immediately to the exhaustive true/false proof. On completion
here the proof process will return a "false" if no "true"
instances exist. Otherwise it will return a "true" with a list of
all "true" instances (one or more).

The logic programming exists here in that the query itself is
regarded as an "assertion" by the user whose proof remains
up to the software. The assertion is either "true" (one or
more true instances) or "false" (incomplete or no true
instances).

On re-referencing your example, which I probably need to do
to format into a more readable manner, I see an "insert"
assertion and a "select" assertion. I call these assertions
because the user is stating they can be done, that the
information is sufficient, and that the order of the names
(data) and conditions (logic) are unimportant: their ordering
for determining access to the database falls upon the
database logic engine.

Contrast this with the "read ("select") into" and "write
("insert") from" of "standard" file management. Here the
ordering of the data in the "in" or "from" clauses must exactly
match that defined for the file. That remains a programmer
responsibility. If the desired output form differs from the
stored form, the reordering is also a programmer
responsibility. The conditions lie outside the input/output
statements themselves. Their truth value, determined by the
programmer reading every record, is also a programmer
responsibility.

I don't know what the remaining 44K of code contains. I read
the "create trigger", "insert", and "select" statements as
assertions. They may not look like it to you, but I look at
them as saying "what" you want done, leaving it up to the
software to say "how", and indicating if it could do it ("true")
or not ("false"). If "false", giving a reason (incomplete or no
true instances) for failure.

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

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 [ 07 | August | 2003 ]

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.