SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Wed, 7 May 2008 11:38:28 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	<scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A fourth try about FORTH (and other things)

Content Type: text/plain

Greg,

I, too, have faced rejection recently in trying to respond directly to
Lindsay's mistaken belief that a connection between SL/I and IBM exists,
which doesn't.

I do enjoy a protagonist. You get a little nervous when someone doesn't
challenge you. Fortunately between you, Greg, and Steven any remaining
nervous condition hovers near zero.

I do take exception to your "nutshell". The PL/I LRM works just fine and
will continue to do so for those third generation components all of which
will remain in SL/I. That points out that as a "universal" specification
language SL/I has to cover both imperative and declarative modes as any
declarative expression must ultimately decompose into a set of imperative
which remains the only kind current computer architectures use. That
"universal" says that BNF now has an SL/I form. After all BNF is a
specification language. The syntax remains the same: every program element
is a statement; every statement ends in a semi-colon.

We do get an additional statement type, the assertion of declarative
languages. It will include the use of list aggregates on both the left-
(target) and right-hand (source) side of the statement. We get an
additional data attribute, the RANGE attribute, to allow the expressions of
rules governing the data declaration. We get the "additional" operators
from APL which behave no differently from the other aggregate operators of
PL/I.

I do object to the comparison with PROLOG. We borrow nothing from PROLOG.
We use the two-stage proof engine of logic programming. We use predicate
instead of causal logic. Moreover PROLOG has no means of completely
specifying itself. PROLOG has an "awkward" means of implementing
(expressing) a case control structure, where the order of the "if" sequence
must remain determinate.

To suggest then that we somehow have a mish-mash of desperate components
somehow mangled together to make a whole belies the elegance of the language
bereft of those deficiencies in other languages. While PL/I supports
null-terminate varying length character strings via the "varyingz"
attribute, it offers an alternate non-null-terminate form, which it also
uses to allow fixed and varying length bit strings, which C and its
derivates cannot. So much for closeness to machine language.

We look at FORTH to develop a detailed understanding of a threaded
interpretive language (TIL). That requires that we develop a detailed
understanding of assembly language. As a result we will have an intimate
understanding of the relationship of an HLL expression along with its
assembly language equivalent. At the lowest level that will provide the 1:1
equivalence necessary between the two that Steven questioned in our monthly
meeting. I assert that Intel provides three forms for each processor
instruction of machine language, assembly language, and HLL. Thus Intel
offers such 1:1 equivalence which we will do the same using SL/I in a way
essentially identical.

I have maintained that every language has a "cultural" aspect, a way of
viewing its analysis of a situation superior to any other. It's important
that we understand each view from APL, LISP, FORTH, and logic programming so
that we can apply them properly to a language which incorporates portions of
them all.

I fully expect that one we do FORTH in FORTH, that we have this lowest
assembly language and HLL connection, that we will do FORTH in SL/I. We
will change the parser to SL/I. We will change the (stack) engine to SL/I.
Then through a process of iteration expand it to include the list aggregate,
the APL operators, and all of PL/I according to its syntax and semantic
rules. Then we will add in the GUI to our editor, have our interpretive
form, implement our two-stage proof engine, and proceed accordingly to a
full SL/I and Developer's Assistant.

So I don't regard FORTH as some tangential venture, but as a "logical"
starting point for a full-fledge SL/I, insuring our competency and
understanding from machine language on up through all higher levels. I
expect we will go from a FORTH-TIL to a SL/I-TIL. That will allow us to
fully expand to a full SL/I interpreter with all the necessary components to
support our tool. This covers completely all aspects of developer
productivity claimed for this approach. Therein the truth or falsity of
claims made will come to rest. All that will remain is its application to a
compiler form.

Our LRM has to include all of this. We will grow it incrementally during
our implementation as we add the necessary components. We may decide to add
as optional the more formal symbolic form of APL operators, e.g. "true" and
or, as well as the left-arrow assignment/assertion designation. This latter
will leave the "=" symbol with only its logical use in expressions.

While I know people get in a hurry to get to some endpoint by adopting or
using something else along the way, I hope they will eventually understand
the "true" meaning of a universal specification/programming language. So
once we get to a SL/I-TIL, we can begin the process of specifying our data
directory/repository in SL/I calling on a database manager written in SL/I.
We have all the source for all of this in a single source library.

As much as I can sympathize with impatience of getting to an endpoint for
what it means when you get there, I feel the journey itself of even greater
importance in establishing the open source goal of independent development.

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

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 [ 07 | May | 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.