SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Thu, 24 Jul 2003 07:36:23 PDT7
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: August meeting

Content Type: text/plain

Peter Skye writes:
"This is a very different stance from your Warpicity project,
yes? In that project you seemed to promote structured
specification and, simultaneously, besmirched much syntax."

No. The Warpicity proposal included three items: (1) an user
organization, (2) its staffing, and (3) new methods. The new
methods included a data repository/directory, a universal
specification language, and a single tool, The Developer's
Assistant. From that time until now I had proposed using logic
programming with a language based on PL/I syntax and data
types, APL operators along with symbol set, and LISP's list
data aggregate and operators.

I continue to maintain that these three contain all the features
(and possibly more) than any other available programming
language and more likely all other programming languages
combined. Based on my experience I would almost make the
previous claim on PL/I alone except for the logic programming.

Beyond the two-stage proof engine of logic programming, the
completeness proof and the exhaustive true/false proof, you
have to have some means of incorporating software-enforced
rules, particularly those associated with data. You also need
to decide on using either clausal or predicate logic. For rules
on data I added the "range" option to the data declaration
statement. I chose to use predicate logic for its ability to
automatically generate an exhaustive set of test data:
enumerate all possible combinations of data values.

I like PL/I syntax for its simplicity: (1) every program element
is a statement, and (2) every statement ends in semi-colon.
Early on IBM was "kind" enough to publish a manual on "List
Processing in PL/I" which basically included creation of lists as
well as the "basic" list operators. PL/I shares with APL the
use of aggregate operands, but not as extensively. It does
not include some of the APL operators. It does, however,
include every known type of data element. It's range of
exception handling capabilities have never been matched in
any other programming language or combination thereof.

So PL/I is my base or starting point. It's a matter of picking
the most powerful and complete programming language
available and not some other like C++, JAVA, or C# to which
you have to continually add things just to get to that point.
These languages, for example, have yet to achieve feature
levels available in PL/I over 30 years ago.

"I've never investigated writing an OS/2 device driver in PL/I.
The assembler stub header which is used on drivers written in
C could just as easily be used with PL/I, but the PL/I package
supplied by IBM has a heavy reliance on linked libraries which
might make a PL/I-based OS/2 device driver impossible. Some
day ("when I have time") I'd still like to investigate this
possibility."

Well, you have just shown why you cannot not write a device
driver completely in C: you require an assembly language stub.
The truth is you can't use the stub with PL/I. Therefore you
cannot write the remaining source in PL/I. Nor can you write
it in C++, JAVA, PROLOG, LISP, or APL, just to mention a few.

The real question you need to ask is "Why not?". It relates to
the fact that the form of the compiled object module is
implementer-, not programmer-determined: we have no means
in source code of specifying the structure of the resulting
program. That changes in a universal specification language
because the resulting structure is simply another set of
specifications. You pick the set you want to get the structure
you want.

We have tools upon tools, one tool compensating for the lack
of another, because up to now, prior to the advent of the
open source movement, a set of protective, proprietary tools.
Unfortunately we have carried the same fragmented,
incomplete tool concepts over into open source. Getting the
open source community off this paradigm remains a challenge.

We know that programs have a structure. We have structures
as a data aggregate. So why not allow a program take on
the form of a data object specifiable in source code?

"Which disassembler do you use, Lynn?"

The DOS-based "DisDoc", if I can find it. I don't know that I
have it on this machine. It's been so long since I've used it.

"...So you *can* "process program structures as you would
any other data object", but don't expect it to be simple. ..."

Complete disassembly requires an interactive environment
involving the user as part of the software process. You
correctly point out some of the difficulties involved. I've
considered writing an interactive disassembler in PL/I as a
"step up" from the peg solitaire solution. Maybe we can get
Ben to consider writing one in APL.

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

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

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

Return to [ 24 | July | 2003 ]

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.