SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 14 Aug 2008 08:42:00 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Full On Programming SIG This Sat.

Content Type: text/plain

At the moment, Sheridan, just you and I engaging in this discussion. As
usual I have reasons below the surface for having directed this use of
Forth as a means forward on our project. I have faced accusations of
somehow going off track in doing so by selecting something seemingly
unrelated to SL/I and the Developer's Assistant.

I have claimed that programmer productivity increases in interpretive
mode while program productivity increases in compile mode. Both of
these relate to a concept of "throughput" and "transaction rate". If a
valid claim and more importantly a verifiable one, then a tool which
produces an executable from source should seek to maximise productivity
based on the user, programmer or production.

At the moment and throughout our IT history production as user has
dominated the executable from source tools, i.e. compilers. With few
exceptions, e.g. IBM Basic which offered separate interpretive and
compile tools, interpretive and compiled languages have gone their
separate ways in terms of crossing modes.

IBM did offer an interpretive form of PL/I...in a separate packaging and
thus a dual cost. IBM Yorktown Research attempted to produce a compiler
for REXX using Fortran, in my opinion stupidly so. They should have
selected PL/I to overcome REXX's habit of dynamic assignment of same
name variable attributes, e.g. character and arithmetic. PL/I has the
BEGIN block which allows multiple definitions in effect within the same
procedure.

I have further claimed that three programming languages--LISP, APL,
PL/I--encompass more than all other first-, second-, and
third-generation imperative languages combined. Two of these, LISP and
APL, remain interpretive only while one, PL/I, has at least offered a
choice of either...though separately. Without at this point addressing
what occurs in a shift to fourth-generation, which Forth despite its
author's claim is not, it would seem that the proposed SL/I
implementation tool, the Developer's Assistant, could and should allow
both modes in a single package.

As we have gone through before interpreters and compilers essentially
perform the same processes of editing, syntax checking, semantic
checking and code generation, differing only in code generation. Now we
have nowhere accounted for the differences, specifically why in
execution interpretive should execute more slowly than compiled code or
measured the actual difference.

Regardless of anything else we have three basic components which must
exist: data, operators and control structures. We have two types of
data, elements and aggregates. We have three types of aggregates:
arrays, structures and list with unlimited nested combinations. Thus we
need to define operators supporting both elements and aggregates as our
three language choices do...and Forth does not.

Thus I propose we begin where we don't want to end up. We begin with
data element only operators, master the operators on them at the element
level and then expand them to aggregate form. we can't do that without
involving the use of assembly language, the language of code generation.
I see a progression from Forth to essentially APL with array and
structure aggregates, facing the challenge of extensions using list
aggregates. If we meet that challenge, which we can, we will have most
of the core data and operators of SL/I. We will have both their
interpretive and compiled forms. Somewhere in all this we can shift our
syntax from Forth to SL/I. That I would hope would lay to rest the
concern that we have somehow gone off track in this choice of Forth as a
starting point.

Also along the way we will have covered the control structures of
decision (if then...else..., case), iteration (do...end, do while...end,
do until...end, and do forever...end) and sequence (statement or a
statement followed by another statement or control structure or a
sequence followed by another). They have in common the characteristic
one in entry, one out exit points.

In fourth generation mode as part of the exhaustive true/false proof
using predicate logic where the software generates the test data based
on programmer-defined rules that we exhaustively test any control
structure or any sequence (path) of control structures exhaustively.
That should lay to rest any concerns that an application poses too many
paths to allow exhaustive testing and thus the need beyond regressive
testing of extending outward to alpha and beta testing as well as testers.

All this has to occur in the software, which means we have to write the
source. Now LISP, APL, and PL/I operate on other than NULL-terminated
strings. PL/I offers support for NULL-terminated character strings, but
its support for non-NULL-terminated means it supports fixed- and
variable-length bit strings which separates it and SL/I from C and its
derivatives in actually being closer to machine language...another false
C claim.

From my perspective Forth provides an immediate operational starting
point toward a full development of SL/I and the Developer's Assistant.
As we make each shift away from "standard" Forth, as we expand more
toward SL/I, we will have answered the critics about the claims. Part
of that shift involves implementing implicit and explicit rules for data
conversion from character to arithmetic, between arithmetic types,
between character and bit strings, for expanded stream and record i-o of
PL/I, for the exception handling of PL/I, and Lord know what other
features of PL/I making it the most complete programming language ever
until the advent of SL/I.

Somewhere along the way we will do away with the demon of the current OO
technology. We will look at the principle of inheritance with a
solution that avoids the use of class libraries and thus the mutual
incompatibilities involved preventing their mixed use in a solution. We
should note that the condition occurs in current OO technology though it
didn't exist previously.

This obviously leads and I hope answered the "source-only" approach I
advocate including the use only of a single source library. The
source-only approach in interpretive mode operates across module
boundaries regardless of their executable form in compiled mode. This
leads to a level of testing, problem detection and correction
unavailable to compiled mode, even to current source-level debugging tools.

At this point the only question relative to having a full Programming
SIG presentation this Saturday relates to the audience support. If it
is just thee and me, then we can carry it on here. It's not for the
lack of presenting a development path with milestones to take us from
Forth to SL/I and the Developer's Assistant.

What do you think? This is the "you" on this list.

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

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 [ 14 | August | 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.