SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 11 | February | 2005 ]

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


Date: Fri, 11 Feb 2005 06:55:03 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: Open Source Object Rexx

Content Type: text/plain

Peter,

The syntax is PL/I. Every program element is a statement.
Every statement ends in a semi-colon. That includes
statement group delimiters, e.g. 'do;' and 'end;' instead of '('
and ')' of C. You can have multiple statements in a line or you
can have multiple lines in a statement. Basically it's free form.

Thus one reason for choosing the PL/I syntax lies in its
minimal rules and lack of restrictions. For example, PL/I has
keywords, but not reserved words, i.e. words that have
restricted meanings or use.

Another reason for choosing PL/I syntax lies in its simple rule
for expression evaluation: all expressions are evaluated on an
element by element basis. This includes expressions
containing aggregates like arrays and structures. Thus in PL/I
the element is king, inviolate. The element by element
evaluation also includes conversion between data types
arithmetic to arithmetic, e.g. binary to decimal, string to string,
e.g. character to bit, and arithmetic to string, e.g. bit to
decimal. You can have any mix of string, arithmetic, and
logical operations in an expression involving element and
array variables.

Now I don't have to provide examples of something that has
existed for 40 years. Pick up you PL/I Language Reference
manual and its filled to the brim with examples.

Now what you will notice if you do this is that it contains a
sections on "Notation conventions used in this book", "How to
read the syntax diagrams", and "Industry standards used".
Those are means to specify PL/I, but they are not PL/I.
Therein lies the difference between PL/I and PL/E. In PL/E
the notation conventions, syntax diagrams (rules), and
industry standards exist within PL/E statements: it is
self-defining.

That says that PL/E incorporates BNF (Backus-Normal Form)
within its syntax. Thus you can use PL/E to specify itself.

That means if you have a PL/E statement "dcl fanny fixed
dec(7,2);" that you have a PL/E parser written in PL/E that
recognizes the statement type (data declaration), the data
name, and the data attributes, all of which have more PL/E
specifications regarding their use.

For example, suppose you decide that no variable name
should exceed 32 characters or less than 5. The variable
name is a string. In going to the name validation procedure
where it is pass as an input parameter as a character string
say "alpha", in the procedure "alpha" would be declared as
"dcl alpha char(5,32);". You could even define what
characters and in what order they could appear within the
string through the use of the "range" attribute in the declare.

Thus you have the means within PL/E to define its own
syntax. Now did we have to change something in PL/I to do
this. Yes. We had to allow a lower as well as an upper
bound on string length. We had to add the "range" attribute
which defines the values or rules of formation for a data
variable. But we did not change the syntax rules.

Now why bother? The old way works. Why emphasize the
use of a single language? The old way works. Why insist on
using a two-stage proof engine? The old way works. Why
not stay with incompatible class libraries? The old way
works. Well, the old way doesn't provide for a 50 times
reduction in time and 200 times reduction in cost of software
development and maintenance. Other than that you can stick
with the old way...and watch the jobs get outsourced to
cheaper labor.

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

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".

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


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

Return to [ 11 | February | 2005 ]



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.