Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site orca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!tektronix!orca!andrew
From: andrew@orca.UUCP (Andrew Klossner)
Newsgroups: net.lang
Subject: ANSI Basic
Message-ID: <1385@orca.UUCP>
Date: Thu, 7-Mar-85 22:57:25 EST
Article-I.D.: orca.1385
Posted: Thu Mar  7 22:57:25 1985
Date-Received: Sun, 10-Mar-85 06:21:03 EST
Organization: Tektronix, Wilsonville OR
Lines: 135


This note is to clear up some of the confusion, expressed in recent
articles here, about ANSI Basic.  I am a member of the ANSI Basic
standardization committee (ANSI X3J2) and just finished leading a
project to implement this language on the Tektronix 6000 family of
computers.  (Micro-review: CPU is National 32016 or 32032; OS is
extended 4.2BSD; great networking; I like it.)

The ANSI Basic defining document is technically still a "draft
proposal".  It is in essentially its final form and is now undergoing
the formalities of the transition to an ANSI standard.  This should all
be finished up in early 1986.  The exact same document is on its way to
becoming an ISO (International Standards Organization) standard *and*
an ECMA (European Computer Manufacturers Assocation or something like
that) standard, and the three standardization committees hold regular
joint meetings to maintain this.

The document is 320 pages long, much smaller than the PL/I standard.  A
capsule list of features is: the usual numeric and string data types
(no integers); arrays; practically every structured programming
construct ever invented (FOR/NEXT, DO/LOOP/EXIT DO, SELECT/CASE) and
all the unstructured ones (GOTO, GOSUB, ON..GOTO); function and
subroutine procedures but with a maximum nesting of two (there are
"internal" and "external" procedures); a somewhat unwieldy I/O
sublanguage that's an amalgam of many existing implentations; exception
(runtime error) trapping; an optional graphics chapter based on GKS
level 0b (optional because not everyone has a graphics device); an
optional concurrency chapter that's very popular in Europe; an optional
business arithmetic (BCD) chapter.

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
(isn't demand paging wonderful!) and is chock full of local extensions.
True Basic, a variant of the standard from Drs. Kurtz and Kemeny at
Dartmouth College (the original inventors of Basic), runs on the IBM PC
and Macintosh and is available, together with a book, for just under
$100 from Addison-Wesley.  Watch for it in bookstores, as A-W is
gearing up for a big marketing push.  IBM has expressed an interest in
distributing the PC version.  The other implementation that I know
about is being done by Olivetti in Italy.

To deal with some specific net complaints:

	"Impossible to interpret."

The folks at Touch Techologies would argue with that.  It's easy to get
this impression from a quick reading of the standard, though.  What is
actually there are restrictions to make it easy to both interpret and
compile; for example, a program must have a corresponding NEXT
statement lexically following each FOR statement.  You could read that
to require that an interpreter make a pre-scan of the program before
beginning execution, but in fact there is no such requirement; you can
issue a runtime error if you run out of program without finding the
NEXT, or you can extend your language to define a specific meaning for
a FOR without a NEXT.

	"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, so this might have
looked like a third way.  The two ways are there because data objects
in ANSI Basic have more attributes than just numeric/type and
scalar/array; one is that you can declare a maximum size on your
(variable-sized) strings, the default being an implementation-defined
figure no less than 132.  A DECLARE statement was introduced to allow
all of these attributes to be specified in a single statement.  The DIM
statement was retained to make it easy to run existing Basic programs.

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

There's the standard DEF which defines a function in a single line, e.g.,

	DEF sin(x)=sqrt(1-cos(x)^2)

There's FUNCTION and EXTERNAL FUNCTION to define multiple-line function
bodies.  There's SUB and EXTERNAL SUB to define subprograms.
(FUNCTIONs and SUBprograms are reminiscent of the corresponding objects
in Fortran, except that they can be internal.)  I guess that makes
five, but it doesn't seem excessive.  Program chaining is something
that most Basics have; it wouldn't have been reasonable not to specify
a chain construct in the standard.

	"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.
This chapter was written by implementors in Europe, and this
concurrency is running robots in factories now.

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

The only new REQUIREments that I can think of are:

  1) All arrays must be declared as such; you can't just start using an
     array.  This seems reasonable in light of modern ideas about
     programming.  A big reason for this was to disambiguate array
     expressions when the popular MAT statements were added to the
     language.

  2) The standard requires that assignment statements begin with the
     keyword LET.  I don't know of any implementations that didn't add
     the obvious enhancement and make LET optional.  This was a
     religious issue in the committee.

	"Makes BCD (inefficient) floating point the standard to
	preserve precision, then doesn't bother to provide integers."

You don't have to implement BCD to conform to the standard.  We use an
IEEE floating point chip.  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.
Here's an example of the problem:  how big are integers?  Are they 16
bits, or 32 bits, or is it up the implementation?  Don't leave it up
to the implementation because I want my program port to all systems.
16 bits is no good because my VAX does integers in 32 bits; why
penalize me?  32 bits is no good because my Z80 has to do a lot of work
to support them and all I really need is 16 bits.

An optional chapter on integer arithmetic will be forthcoming in a
couple of years.

I don't argue that ANSI Basic is the best of all programming languages.
(I could work up an argument for Algol 68, though ...)  The point of
ANSI Basic is that it is a concensus.  Most of the major manufacturers
were represented, and, after many long years, we came to an agreement
on a standard dialect of Basic to implement across several computers.
Surely this isn't bad news.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)       [UUCP]
                       (orca!andrew.tektronix@csnet-relay)  [ARPA]