SCOUG-Programming Mailing List Archives
Return to [ 19 |
June |
2008 ]
Content Type: text/plain
On Sun, 15 Jun 2008, "Lynn H. Maxson" wrote:
> 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.
>
> LUMPL LRM> One, we need a formal means of defining a list aggregate construct. In
> LUMPL LRM> PL/I all data definitions, thus all "referents", occur in a data
> LUMPL LRM> declaration statement which begins with a "dcl" or "declare" and of
> LUMPL LRM> course ends in a semi-colon. None of those statements beginning with
> LUMPL LRM> "int", "float", or "char" which accounts for "reserved" words in C and
> LUMPL LRM> elsewhere, but not in PL/I. In fact neither "dcl" or "declare" are
> LUMPL LRM> reserved words in PL/I, only "keywords" which relies on the statement
> LUMPL LRM> context for their actual meaning.
> LUMPL LRM>
> LUMPL LRM> Now lists are either single-linked (next entry or null (end of list)) or
> LUMPL LRM> double-linked (
> LUMPL LRM> previous or next entry or null (beginning or end of list)). An entry is
> LUMPL LRM> either an element or an aggregate (array, structure, or list). It
> LUMPL LRM> doesn't seem a stretch to think of something like "dcl 1 army double, 2
> LUMPL LRM> (some element or aggregate)...;" That's one down.
> LUMPL LRM>
> LUMPL LRM> Two, we need some means for assigning rules to referents. Those rules
> LUMPL LRM> can include inclusive listing of values (the same as type 88 does
> LUMPL LRM> currently in COBOL) or a range of values as in "10...999" or some
> LUMPL LRM> combination thereof. It can also include "referential integrity" such
> LUMPL LRM> as in the instance of a client like SCE which has two or more data
> LUMPL LRM> fields in which the values of one determine the possible values
> LUMPL LRM> associated with the other(s). Implemented here just as they are in DB2,
> LUMPL LRM> 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.
NOT EVEN CLOSE. You are still talking LUMPL here.
Go get a copy of SC27-1460-07 from IBM and stick the section "LUMPL LRM"
at the end of chapter 8. Then give an example of how you use these
additions to make a simple list. Maybe twenty to twenty five lines of
code with a simple explaination of how the code works. You should
be able to do it all in a page or two.
AND THEN
Please explain how LUMPL improves on the PL/I list processing example
on pages 244 and 245 in the manual.
--
Gregory W. Smith (WD9GAY) gsmith@well.com
=====================================================
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 [ 19 |
June |
2008 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
|
