SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 23 Feb 2006 00:11:39 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: Trip preparation

Content Type: text/plain

Sheridan, I can appreciate your confusion. Just be patient.
We will get to it. I did notice that jEdit supported PL/I. LPEX
does as well. That means we have a least two sources for
the syntax rules.

At one time I compiled the entire .h libraries, actually their
PL/I equivalents which came with the VisualAge PL/I products.
It took me a number of iterations with "define" switches to
insure that I got them all, essentially the entire set of OS/2
APIs.

We had two projects underway, both of which have since
grown dormant, to write an OS/2 clone. I won't go into how
one project became two, but both needed ultimately to
include all the OS/2 APIs.

After compiling all the APIs I had a full cross-reference and
attribute listing of all API names as well as all variables
associated with them. I assume you could do the same with C,
but I chose to do it with PL/I.

To clean up the APIs, to eliminate the problem of homonyms
(same name, different referents) and synonyms (different
names, same referent), would have taken some effort. The
most serious homonym problem came in the name "rc", a
generic reference in C programming to "return code". Each
API has a specific set of return codes. Accordingly each
separate set should have a different "return code" name.

Assuming SL/I as the programming language that would have
let us define each return code in a "declare" statement with
its possible range of values, e.g. "dcl rc2064 fixed bin (31)
unsigned range (0, 4, 8, 12);". Thus using an assignment
statement like "rc2064 = some_api(parm1, parm2, parm3);"
would insure that only valid return codes occurred on
execution of the API. Otherwise it would generate an
exception.

So if you were writing your own version of OS/2, you could
use the software to verify the return code values on
execution of the APIs under test. Moreover you could use the
predicate logic I discussed earlier to specify ranges of values
for each of the parms associated with the API. That means
you could in interpretive mode mark an API instance, set the
test range of values for its parms, and execute the API with
test input data generated by the software.

Now you simply cannot do that in compiled mode with the
same level of ease and flexibility as in interpretive mode using
predicate logic. I would have said that you cannot do that in
compiled mode period, but someone would say you could
write the logic which enumerated the different value sets that
the software using predicate logic does. I would respond
with, "My point exactly." Yet another example of letting
people do what software cannot and software what people
need not. Then we could get into what happens when you
want to change value ranges.

We could when we get to the syntax checking of PL/I add the
feature of the "range" attribute. At some point then we could
add the list aggregate as a data type along with "assertion"
statements in addition to the standard "assignment"
statements. We could do this until we incrementally reached
SL/I, which I first termed as PL/E for Programming
Language/Extensible instead of something like PL/XII.

One of the advantages of getting to SL/I and our tool lies in
the fact that the .c, .h, or dot-anything disappear along with
the "define" and the "include" statements. Just be patient.

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

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 [ 23 | February | 2006 ]

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.