SCOUG-Programming Mailing List Archives
Return to [ 20 |
June |
2008 ]
Content Type: text/plain
Greg,
As the LRM you mentioned illustrates you can do list processing in all
its forms from within PL/I. Even in the example it offers PL/I has no
clue that it is a list much less another aggregate form. Note that PL/I
allows you to describe a single entry in a list, but offers no means of
processing, i.e. performing operations, on the list as a whole, i.e. as
an aggregate.
We should note here that the same is true for PL/I file processing. We
can only operate on a record at a time though a file is an aggregate.
APL on the other hand defines a file as an aggregate and allows
operations on it as such in the same concept used by AWK. The same
limitation occurs when accessing any of the database management forms
(network, hierarchical, relational): one entry at a time processing.
Note the difference between an SQL SELECT statement which will return
all true instances on output and how languages like C, PL/I, COBOL, etc.
with the same embedded SQL statement must request each true instance one
at a time. Thus it is not a matter of achieving the same result, i.e.
processing of a list, but a difference of the effort to do so.
Just for completeness here we should consider queues where we have three
types: FIFO, LIFO, and INDEXED. These too exists as lists with builtin
rules relative to the ordering of entries on their creation. Again we
have entry at a time processing of an aggregate and no means of
expressing that operation as an aggregate one.
Now I don't want you to think that I am avoiding responding to your
direct requests of defining a list and providing an example. In your
reading in the LRM to which you refer you will note that a list has
three different forms: uni-directional (next entry only and null for
last), bi-directional (previous and next entries with null previous for
first and null next for last) and circular (either next entry only or
previous and next entries). Thus to completely designate the list types
we need only the attributes of "single'(uni-), 'double'(bi-), and
'circular'.
Note that means that none of the 'pointers' defined in the LRM examples
appear explicitly in the list declaration, only implicitly by the
attributes. As is typical in PL/I (as in other languages) where you
have necessary but undeclared attributes, you have default values.
Personally I would choose 'double' and non-circular as the default.
Actually SL/I, as those specifications are part of the language itself,
its self-defining capability, you could specify a different default.
Now you ask for an example. I choose to use an SQL SELECT statement. A
generic form would look like the following: SELECT *(all) or an ordered
set of entry values FROM a list, file, queue or database WHERE the
follwing conditions apply and assign the result to a conforming list
aggregate. Further to have this occur in a nesting manner on the
right-hand side of the expression as possible with SQL today.
Now notice that you have taken the SELECT from SQL outside that box into
a more universal one. It does all that AWK does or DL/I(IMS) or TOTAL
(network), INFORMIX, ADABAS, and so on. It means that you don't have a
separate AI (or database) language different from its implementing one.
As a final note, at least for this piece, we have taken the concept of a
list beyond that of LISP, APL, PL/I, etc to a generic aggregate form. We
have implemented it in a single specification language. And, oh, yes,
please note that an SQL statement ends in a semi-colon.
Whie I recognize, Greg, that I will never completely satisfy you at some
point you will realize the comprehensive analysis that preceded the
Warpicity Proposal. I did think outside the box. I didn't limit myself
to defining an "exclusive" imperative or declarative language, but one
which included both forms. I knew of the awkward "entry at a time"
processing of embedded SQL in PL/I, COBOL, and C which didn't occur in
AI languages implemented in PL/I and C. I just didn't see the need to
have two or more languages when one would do.
=====================================================
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 [ 20 |
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.
| 
