SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sun, 8 Jun 2008 17:47:27 -0700
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: A failure to communicate.....

Content Type: text/plain

As the warden says: "What we have here is a failure to communicate."

In a nutshell, I thought that I had clearly made a point. Instead a
twisted version of my comments gets reposted as a prelude to a long
missive that does not address what I said.

To be specific, I am referring to the following:

On Thu, 15 May 2008, "Lynn H. Maxson" posted:
> I did want to address again Greg's demand about BNF in SL/I. Whether we
> call it the Backus-Normal or Backus-Naur Form Backus, the "father" of
> Fortran, had to have a means of defining the language syntax for which
> Fortran seemed ill-suited. Defining syntax has taken on a number of
> forms or variations since then from that of LEX to that of the syntax
> diagrams IBM uses in its LRMs.

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

This is NOT a "demand about BNF in SL/I." Maybe a few more restatements
will make things clear.

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

* OR *

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

* OR *

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

* OR *

> Fine with me. We can FLUSH the BNF DOWN THE TOILETTE and start
> writing out the language specification right now in SL/I.

* OR *

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

* OR *

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

More to the point, there is NO SUCH THING as SL/I.

SL/I has NO specification that anyone can point to.

SL/I is what Lynn thinks it is -- neither more nor less.
And I still have no clear idea what SL/I is. (This seems like
the Through the Looking Glass encounter between Humpty Dumpty and
Alice:
`When I use a word,' Humpty Dumpty said in rather a scornful
tone, `it means just what I choose it to mean -- neither
more nor less.')

So, to make my point clear, I will no longer refer to this ficticious
language as SL/I. Instead I will use a much more accurate name
for the implimentaton language for the Developer's Assistant:
LUMPL. The acronym stands for Lynn's Ultimate Mythical Programming
Language.

Now to restate the point that I was trying to make. I will accept
the name "SL/I" when I see a language specification for LUMPL written
in LUMPL.

So we will look into FORTH as a first step to LUMPL-TIL. Then we will
add a dash of APL to our LUMP-TIL. Still, this is NOT SL/I--and we
have no clue as to how close LUMP-TIL with a dash of APL has brought
us to this ultimate programming language, SL/I. (Maybe we are now
at SL/one-quarter, or SL/one-third.)

Then we will move on to LUMP-TIL with APL A*N*D a list aggregate data
type. Then add in the logic engine. Sooner or later we will get there.
When LUMP-TIL turns into SL/I, though, is anybody's guess.

So the saga of the Developer's Assistant continues. Scheherazade went
on for 1,001 nights. The story of the Developer's Assistant has had
a run three times as long.
--
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 [ 08 | 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.