SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Thu, 14 Aug 2008 22:16:43 -0700
From:	Sheridan George <s-geo@usa.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

I'm all for having a meeting on setting up some tasks using Forth. How do we get the word out to
whomever gets the word out.

Sheridan

Lynn H. Maxson wrote:
> 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".
>
> =====================================================
>
>
>
>
>
>

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

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.