Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2.fluke 9/24/84; site vax2.fluke.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!vax135!cornell!uw-beaver!fluke!kurt
From: kurt@fluke.UUCP (Kurt Guntheroth)
Newsgroups: net.lang
Subject: re: ANSI BASIC
Message-ID: <443@vax2.fluke.UUCP>
Date: Mon, 11-Mar-85 13:53:38 EST
Article-I.D.: vax2.443
Posted: Mon Mar 11 13:53:38 1985
Date-Received: Tue, 12-Mar-85 23:12:22 EST
Reply-To: kurt@fluke.UUCP (& Guntheroth)
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 148

Well, I don't think I misread the ANSI BASIC standard in any major way.  I
just have serious reservations about the language called ANSI BASIC.  I
appreciate Andrew Klossner's reply (>) to my statements (>>) on the subject
and would like now to question his answers.

> The ANSI Basic defining document is technically still a "draft
> proposal". 

OK.  If I said standard, I meant 'draft standard' but apparently there is to
be no difference between the 'draft' and the 'standard'.  By the way, as
standards documents go I like the ANSI BASIC document.  It is not too
difficult to read and seems to be relatively complete and descriptive.  Good
Job Guys.

> As to language size, Touch Technologies (San Diego) wrote a strictly
> interpreted implementation for the VAX that fits in 80k -- and includes
> extensions to deal with database management.  By contrast, the
> Tektronix implementation is a compiler wrapped up in an interactive
> environment that makes it look like an interpreter; it takes about 800k.

I reat my case.  I have a commodore 64 with BASIC in 8K of ROM.  I challenge
ANYONE to get ANSI standard BASIC in 8K, 16K or 32K of ROM.  This is
actually the central thrust of my complaint; that the language we called
BASIC is the kind of small, simple language that you could learn in a few
hours and implement in a few man-months.  The language the ANSI standard
calls BASIC takes 800K of memory, man-years to implement, has "every
structured statement" and yet still wimps out on things like integers.

> To deal with some specific net complaints:

>>"Impossible to interpret."

OK.  I meant 'impossible' in the sense that it was inefficient to the extent
of not being worthwhile.  Any real computer scientist knows that ANY
language can be interpreted.  Recent proof was provided by the ADA/ED
interpreter in Prolog yet.  OK, people have built BASIC interpreters for
ANSI BASIC.  I will let the marketplace judge them.  My guess is that they
will make your Macintosh look a lot like a Z80 in terms of speed.  Maybe
that is acceptable to the marketplace, but I would like more of my processor
cycles to go towards useful work, and fewer of them to go to checking all
the conditions that must be checked in ANSI BASIC.

>> "Three ways to declare an array."

> There are only two ways.  But you can change the size of an array
> dynamically during an array assignment or input.

You can declare an array's size in a DIM statement and also in a
DECLARE (?) statement.  In a real/useful language, there is one way to
do a thing.  This is the point of my complaint.  And about changing
the size dynamically, yes you can do that.  Is that a good thing?
Remember, you DIM'ed it to a particular size, and now you are changing
that.  I would argue that that is not 'good' semantics.  One can
argue that it makes matrix arithmetic easier if you can change the
'shape' of an array.  OK, I'll buy that.  But the standard says you can
change the shape only if the total amount of storage is not greater
than the originally-DIM'ed amount.  If you were going to ignore the DIM
statement, then why the restriction?  This is another point of my complaint;
a bunch of strange restrictions.  My guess is that this restriction was
provided to protect certain implementations where dynamic memory allocation
for arrays was very expensive.  I would guess these would be mainframe
implementations.  My microcomputer BASIC can dynamically allocate memory...

>> "Five ways to denote a function, plus program chaining."

Here it appears I was wrong.  I had originally read the standard to mean
that functions need not return values.  I now believe they must, or cause an
exception at their point of call since they may not be called as procedures.
So functions cannot serve as subprograms.

There ARE two ways to define a FUNCTION, a single-line DEF and the FUNCTION
statement, a little excessive, but needed for compatibility I guess.  Still,
a 'good' language would have ONE way to define a function.  This is an
example of the result of attempting to graft new features onto a language
which cannot easily support them.

There is also a(n optional) second kind of subprogram called a PICTURE which 
is not very different from a subprogram in syntactic appearance.  This seems
excessive to me, but maybe to a graphics expert, the necessity is apparent.

That makes FOUR ways to define a function, if you consider functions and
subprograms as being similar.

>> "Concurrency (an option at least)."

> I don't see anything wrong with adding a chapter which says that, if an
> implementation chooses to add concurrency to the language, it would be
> nice if they would do so in this way so as to enhance portability.

The thing that is wrong with concurrency is that it doesn't belong in BASIC.
People who want concurrency, functions, exception handling, nested scope,
recursion, structured statements, and all that should not even be thinking
about BASIC.  Use Algol-68, or PL/1, or Ada, or some language designed to
support this kind of power, and not a language where these features have
been cobbled onto a framework which cannot really support their weight.
Just calling this language BASIC will not make it easy to use, will not make
it easy to implement.

>> "Breaks 100 percent of all existing Basic programs, no matter how simple
>> due to REQUIRED new syntax."

It appears in my draft that if you don't implement BCD arithmetic, and many
current BASICs don't, that you are REQUIRED to have a line in your program:
" OPTION ARITHMETIC NATIVE"  Thus, any program written in such
a BASIC is already broken.  There is also an OPTION that MUST be included if
your arrays don't start at zero.  This breaks all programs compatible with
the (admittedly inadequate) minimal BASIC standard of 1979.

>> "Makes BCD (inefficient) floating point the standard...

> You don't have to implement BCD to conform to the standard.  We use an
> IEEE floating point chip.

No, but if you don't all your existing programs are broken.  See above.

> Integers weren't implemented because the
> complications to the language would have been massive.  We tried a
> couple of times but couldn't get past the "keep it simple" partisans.

Oh yeah?  Where were these "keep it simple" partisans when the rest of this
stuff got through?  Seriously, though, there are a number of places in BASIC
that require integers.  Line numbers, exception numbers, array indices,
channel numbers, etc.  You should have provided them.  Also, if you don't
have FP hardware, integers are MUCH more efficient than floating point, even
if you had to have them 32 bits long for portability.  You could always have
put in an "OPTION PRECISION n" statement to describe the minimum size of
integers.  It would be totally in keeping with the rest of the standard.


>  -- Andrew Klossner   (decvax!tektronix!orca!andrew)       [UUCP]
>                       (orca!andrew.tektronix@csnet-relay)  [ARPA]
-------------------------------------------------------------------
Lets not erect yet another monument to whatever-feature-you-want-we'll-put-
it-in.  We all know BASIC can never aspire to the heights of PL/1 or
Algol-68.  Lets not forget why BASIC started simple.  Lets make a decision
to expend our talent on a new language design which cleanly implements
features we now consider desirable rather than cobbling them together with
features from 1964 into an unwieldy mass.  Lets bite the bullet and come up
with a new name for our new languages and stop taking BASIC's name in vain.

Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt

-- 
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt