SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Wed, 4 Jun 2008 22:12:31 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: From the bottom up

Content Type: text/plain

Gordon,

That leaves me to believe in the approach I propose. Granted that SL/I
is an HLL technically FORTH is as well. The difference lies in the
perceived difference, the acculturation difference involved in the
optimal use of the language. As a deliberately interpretive language ,
as a threaded interpretive language (TIL) with a very close relationship
to a machine instruction set via a symbolic assembler we begin at a
point at which every HLL must end.

I've had the questioned raised about how SL/I can map into a specific
machine instruction set. I don't expect that to occur in this
undertaking with FORTH. Once we fully understand the logical
equivalence between the "macro" form of a FORTH imperative and its
assembler implementation, we can look at the Intel instruction set
reference manual for pentium-class machines which offers all three
imperative generation forms for each instruction (machine, symbolic
assembler, HLL). We have a logical HLL equivalent in SL/I, thus a
transitional path from writing in symbolic assembler to HLL directly.

The implementation which you downloaded has the "kernel" source. Thus
we do not have to create something. We do have to provide an analysis
which anyone can use essentially to create or modify a kernel on his
own. So we choose to begin at some distance away from where we expect
to end in our HLL. We will reach milestones along the way which will
cause us to rethink our means when we bump up against some limit which
the current implementation will not support. These incremental
extensions will allow us to have the context of the old or existing as
the background in which we need to introduce changes.

We don't do this in isolation divorced from our other programming
language experiences. As a programming SIG early on we expressed an
interest in a means of comparing languages. We know languages differ,
but we didn't have a pre-defined classification scheme for those
differences. This incremental approach with its focus on limits should
allow us to provide a meaningful metric for any programming language.
In the incremental process as we master our understanding of limits and
why they exist we should have a more profound sense of how to evaluate a
programming , i.e. specification, language.

So we will need feedback as we proceed to continually reevaluate how we
got to a particular point and specifically to how we could do it
differently to allow some new participant to have an easier path and
less time to catch up. I don't say that "I" need feedback as this makes
no sense as an active arena for me and a passive one for others. If we
wish to promote a goal of open source of the independent developer, then
we need to use our experiences along the way and the reflection on our
journey to insure it not only for ourselves, but to ease the path for
others who might otherwise not attempt it.

Now you may have bought some book on "Thinking FORTH" which has an
appropriate goal in mind, but perhaps not the best means of doing so.
It has a focus on the language in hopes that will suffice to get you to
think in FORTH. After enough exercise it will probably work.
Personally I think having an intimate knowledge of the assembler source
in the implementation of the FORTH interpreter, of seeing through the
"instructions' eyes" will get us to thinking in terms of a TIL,
including FORTH, much sooner.

I appreciate the feedback. We need to make the journey as easy for us
as possible and easier, if possible, for those who might follow. While
some may shudder at an emphasis on assembly language, the sooner we put
that shibboleth behind us the better.

Regardless of your eventual position on the assertions surrounding SL/I
and the Developer's Assistant, you should feel confident about asserting
and following your own positions. That remains a principal objective of
open source. The more independent open source developers we can bring
onboard the more viable the open source community will become.

The more viable it becomes within the OS/2-eCS community the more likely
we can keep pace with the other communities as well as contribute to
their viability.

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

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 [ 04 | June | 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.