SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sun, 15 Jun 2008 10:04:36 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scougprog <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: The SL/I language reference manual.

Content Type: text/plain

I endure the taunting from Greg Smith and Steven Levine due to the
respect I have for both of them. I would prefer that they transform
themselves from taunters to full-fledged protagonists due to the respect
I have for the audience of these remarks. If an proposal is wrong in
part or whole, they should expose it as such. If it will not have the
intended result in productivity, they should challenge it with reasons
why. In that manner we could establish those parts in question as
either fact or fiction or unproven.

I still shake my head at the charge that no language reference manual
exists for SL/I. It certainly exists for PL/I, a proper subset of
SL/I. At least that much lies in the public domain. Now I have no
reason to change the syntax. In fact we need only three additional
language features to have the complete SL/I.

One, we need a formal means of defining a list aggregate construct. In
PL/I all data definitions, thus all "referents", occur in a data
declaration statement which begins with a "dcl" or "declare" and of
course ends in a semi-colon. None of those statements beginning with
"int", "float", or "char" which accounts for "reserved" words in C and
elsewhere, but not in PL/I. In fact neither "dcl" or "declare" are
reserved words in PL/I, only "keywords" which relies on the statement
context for their actual meaning.

Now lists are either single-linked (next entry or null (end of list)) or
double-linked (
previous or next entry or null (beginning or end of list)). An entry is
either an element or an aggregate (array, structure, or list). It
doesn't seem a stretch to think of something like "dcl 1 army double, 2
(some element or aggregate)...;" That's one down.

Two, we need some means for assigning rules to referents. Those rules
can include inclusive listing of values (the same as type 88 does
currently in COBOL) or a range of values as in "10...999" or some
combination thereof. It can also include "referential integrity" such
as in the instance of a client like SCE which has two or more data
fields in which the values of one determine the possible values
associated with the other(s). Implemented here just as they are in DB2,
Oracle, and MySQL relational databases. That's two down.

Three, the addition of the assertion statement, which is no more than an
assignment statement on steroids. An assignment statement like "a = b +
c;" says that the right-hand side produces a single element value which
replaces that of "a". If "a" is an aggregate and either "b" or "c" or
both are matching aggregates, it simply means that
position-corresponding element results on the right-side replace those
on the left. Now an assertion operates like a SELECT statement in SQL
(which is an assertion) that asks for "all" value results for certain
elements contained in a data aggregate (like a file or a table or in
"storage" equivalent" where certain conditions apply, i.e. result in
"true". That's the right-hand side. The left-hand side contains the
"true" results from the right-hand, just like in SQL. Just like in SQL
it can contain zero (all false) or one or more "true" entries. That's
the way SQL works. That's the way AWK works (for you C fans). That's
the way an assertion in SL/I works. We haven't shown an actual example
of such an assertion which requires a condition like "a = 100...125(b);"
which is the list of elements in "b" entries associated in rows or
records with values of "a" between 100 and 125 inclusive. Of course, it
can be as complicated in terms of "and(&)" and "or(|)" conditions of
PL/I as in SQL or as "nested" also in SQL. That's three down.

There, Greg, you have your language reference manual.

Now I do admit that the PL/I statement "a = b = c;" disturbs me as I
would prefer the APL form of "a <- b = c" where the composite "<-"
corresponds to the single character left-arrow of APL. That would leave
"=" to have only its logical meaning. To do so, however, would mean
changing all such uses in the PL/I language reference manual and would
play into Greg's complaint. As a principle of SL/I lies in its
extensibility, we can actually allow one or both forms to appear
intermixed without confusion in the source.

So at this time I hope we can lay to rest any complaints about the lack
of a language reference manual or the BNF. We include both the
assignment and assertion statements, because eventually every assertion
must translate into a set of one or more assignment statements. We do
not make the "purity" mistake of making a language either imperative or
declarative exclusively. I hope that the previous illustrates the ease
with which they can co-exist in the source.

Now I have yet to have an equally definite deficiency from Steven as the
one from Greg on the need for a language reference manual. I can only
assume that the "assertion" of "50 times time reduction and 200 times
cost reduction" stretches both their credibility comfort zones. But an
assertion is true or false, relying on an operational method of proof.
It may turn out in either instance to vary plus or minus from those numbers.

I would simply assert that instead of arguing over the truth or falsity
of the assertion that they assist in developing the operational method
of proof. In the absence of their assistance in that I would
respectively submit that we keep our remarks about the truth or falsity
or the points inbetween until we get to that point. The proof of the
pudding remains in the eating thereof. It lies at the core of the
scientific method. I simply offer an hypothesis whose truth value
remains in question.

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

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 [ 15 | June | 2008 ]

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.