SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sun, 11 May 2008 12:26:26 -0700
From:	"Gregory W. Smith" <gsmith@well.com >
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

On May 7, 2008, Lynn H. Maxson wrote:
> 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.

Huh?? "PL/I is a subset of SL/I." That is the extent of the language
definition of SL/I??????

If the only LRM we need is PL/I, then the language is PL/I. Or am I missing
something? Do we just need give a team of compiler/interpreter developers a
copy of the PL/I LRM and we will get 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.

Fine with me. We can dispense with the BNF and start writing out the
language specification right now in SL/I.

> 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.

An "Additional Statement Type"? I thought that we only needed the PL/I LRM.

> 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.

And the syntax and semantics of this is already in the PL/I LRM?

> We get the "additional" operators
> from APL which behave no differently from the other aggregate operators of
> PL/I.

Here we go again-- "ADDITIONAL" operators. Defined by which of these
two documents?
PL/I ANSI INCITS 53-1976 (R1998)
APL INCITS/ISO 8485-1989 (R2005)
I assume from your statement that PL/I trumps APL if the standards differ.
No right to left evaluation even if that makes more sense in some cases. It
should be REAL EASY to define operator precedence for the various composite
mathematical operations such as x.+ for matrix multiplication. NO PROBLEM
editing the APL LRM into the PL/I LRM. On the other hand, we could do away
with ANSI/ISO and stick with the IBM definitions of the languages.

>
> I do object to the comparison with PROLOG. We borrow nothing from PROLOG.

Now I am really farblondzhet. NOTHING from PROLOG? What in the world are
we talking about then?

> We use the two-stage proof engine of logic programming. We use predicate
> instead of causal logic.

And the syntax and semantics of the statements to invoke the logic engine
are already in the PL/I LRM. I think I am beginning to get it now.

< ----- Great big SNIP ------ >

> Our LRM has to include all of this. We will grow it incrementally during
> our implementation as we add the necessary components.

Huh??? I thought I understood, and now I see that we have to

G*R*O*W the LRM.

I guess that I have to go back and revise previous view of the
SL/I language. Take one copy of
PL/I ANSI INCITS 53-1976 (R1998)
staple to
APL INCITS/ISO 8485-1989 (R2005)
and staple to
some unspecified logic engine specification having
NOTHING to do with Prolog.

> 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.

I do NOT want "something else", I just want to know what SL/I is -- REALLY.
If you are trynig to sell a sport utility vehicle of programming languages
(SL/I), you have to do better than: "It is the best of our trusty station
wagon (PL/I), and that shiny sports car (APL)." When Detroit rolls out that
shiny new model, it went through the development process of drawings, clay
models, initial concept car, preproduction model, and the first year's model.

> 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.

How do we know when we have our final SL/I-TIL when it seems to be a moving
target?

> 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.

If the journey is more important that the final result, then let's forget
SL/I. Selecting some toy language and going through the Dragon Book will
probably get us up to speed faster.
--
Gregory W. Smith (WD9GAY) gsmith@well.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 [ 11 | 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.