SCOUG-Programming Mailing List Archives

Date:	Wed, 1 Oct 2008 13:01:08 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Getting back to the lesson plan

Content Type: text/plain

While not wanting to interfere with Steven's search for topics for the
monthly meeting I can't say that I appreciate his hijacking an APL
resource from this effort. In truth the APL tutorial remains tangential
to the less plan I had in mine. Maybe I should offer something of an
suggested outline of what I had in mind and the form of the APL support
it would require.

First off we have to establish our comfort zone with the OS/2 open
source FORTH we have selected as our starting point. That means
establishing a comfort zone with working with assembly language. The
goal here lies in everyone successfully compiling the forth.exe executable.

That leads naturally into the internal architecture of FORTH itself,
coming to grips with a threaded interpretive language (TIL),
understanding the stack mechanism, and developing at least the full data
and operator capability of C. Part of that will include a common string
mechanism that includes both character and bit strings (not a C data
type). As ALGOL did for so many years we will not focus on advanced
i-o, only that which FORTH currently supports. That should have us
solidly comfortable with FORTH as well as our ability to add enhancements.

At this point we come to a fork in the road which will run in parallel
throughout the remainder: creating a compiled version of the incremental
interpretive enhancements. We will then have what no other software
offers within a single cover.

Now we will look at what changes we need to make to extend our
element-only operators to aggregates, both array (homogeneous units) and
structures (heterogeneous or what APL2 refers to a mixed-data arrays).

At this point we introduce two of Iverson's important operations in APL:
reduction and selection. As we have introduced bit strings earlier, we
also included bit operators such as "and", "or", "not", "equal", "not
equal", "shift" and "rotate" among others. Thus we can support the set
operators used in selection.

We should note that this support, selection, in APL allowed the
prototyping of System R, the original relational database, to occur.
The selection in fact covers all the capability of the "SELECT"
statement in SQL, I hope for obvious reasons.

Now while FORTH and APL support certain element data types, they do not
support them as completely as PL/I. We need then to see what changes we
need to introduce to extend them to this PL/I level. We need to
introduce the PL/I storage types of static, controlled, automatic and
based along with "area" and pointer data types.

This allows us to introduce the list aggregate, the LIFO, FIFO and
INDEXED queues along with their application in aggregate operations.

I have the feeling that if we proceed along in this manner at some point
we will feel confident enough to switch to at least the syntax of SL/I,
having achieved a PL/I subset at this point. We can expand in this
manner to a full PL/I remaining as a proper subset of SL/I. That
includes the stream (data, list, edit) and record (sequential, direct,
indexed) i-o and the exception handling. In this we will have the PL/I
language reference manual as our guide.

Now armed with the most complete, powerful, functional language, PL/I,
within an interpreter/compiler tool we can take this third generation
HLL and extend it to the fourth generation level of logic programming.
That means that we modify our interpreter/compiler with a two=stage
proof engine. It also means we can introduce the use of predicate logic
and the extensions necessary for automatic test data generation.

If we do this before adding the other logic programming language
features of rules, assertions, etc., we will still have a third
generation language with essentially a non-useful completeness proof
with respect to program organization. That still remains the
developer's responsibility until we introduce the fourth generation
extensions. On the other hand we will have a complete exhaustive
true/false proof engine using predicate logic automatically generating
test data. That alone will offer at least an order of magnitude
productivity improvement over any other test environment in use anywhere.

When we introduce the fourth generation language extensions which in
effect will offer us the same segmented (paragraph) capabilities of
COBOL with the same in-line or out-of-line execution option which COBOL
offers. We have one principal difference with COBOL at this point: we
have unordered segmented code and now use the completeness proof to
organize it optimally for execution.

Somewhere before this we will have specified and incorporated the data
directory/respository. We ill have decided on the database manager
architecture, hierarchical or relations, and done the same in terms of
specified and incorporated. At this point we have a nearly complete
Developer's Assistant tool and a SL/I specification/programming language.

That gives you perhaps more of an outline than you expected or wanted.
Though it may sound scary, that's only due to our not having achieved
our initial goals with FORTH. That comes with a master of assembly
language. Regardless of whatever we do with any HLL along the way we
will do it internally with assembly language. Even when we get of
extending an HLL in terms of its own language it must eventually resolve
into assembly language.

I have no idea when it will occur to Steven to join in so that we can
have the advantage of his experience. Under the plan outlined here we
will have a full APL2 in terms of functionality at some point. We
probably have a "natural" order for development of the operators. I
suspect that it differs from that currently offered. At this point I
would place emphasis on the plan outlined here to get us to our end
goal, steering clear of diversions.

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

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 [ 01 | October | 2008 ]

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.