andrew@orca.UUCP (Andrew Klossner) (03/08/85)
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]mzal@pegasus.UUCP (Mike Zaleski) (03/10/85)
Indented excerpts from: andrew@orca.UUCP (Andrew Klossner)
"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:
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.
It would certainly break every BASIC program I wrote on:
* An early (1974) version of UNIX on a PDP 11/40.
* DEC RSTS/E on a PDP 11/50.
* DEC IAS-11.
* DECsystem 20 BASIC.
I guess you could say I hold to the religous belief that LET is
kind of an unnecessary annoyance.
-- Mike^Z Zaleski@Rutgers [allegra, ihnp4] pegasus!mzalbarmar@mit-eddie.UUCP (Barry Margolin) (03/11/85)
In article <1385@orca.UUCP> andrew@orca.UUCP (Andrew Klossner) writes: >As to language size, Touch Technologies (San Diego) wrote a strictly >interpreted implementation for the VAX that fits in 80k Wow, remember the good old days when a fairly complete BASIC fit in the 4K (or maybe it was 16K) ROM of a TRS-80 model I? Or how about the BASIC I learned to program on, which ran in the 4K address space on a PDP-8 (it used overlays and demand-paged the P-code generated by the cmopiler, but it was still fairly tiny). -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
kurt@fluke.UUCP (Kurt Guntheroth) (03/11/85)
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: "<line number> 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
ndiamond@watdaisy.UUCP (Norman Diamond) (03/12/85)
I do not have a set of open-end wrenches, but I do have a set of pliers.
If I need an open-end wrench but use a pliers, am I using the best tool
for the job? I don't think so. If I had room to store a good set of
tools, and could afford to buy them, I would do so. They are the right
tools for the job.
--
Norman Diamond
UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy@waterloo.csnet
ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa
"Opinions are those of the keyboard, and do not reflect on me or higher-ups."wcs@ho95b.UUCP (Bill Stewart) (03/13/85)
From Barry Margolin: >As to language size, Touch Technologies (San Diego) wrote a strictly > >interpreted implementation for the VAX that fits in 80k > > Wow, remember the good old days when a fairly complete BASIC fit in the > 4K (or maybe it was 16K) ROM of a TRS-80 model I? ......... A friend of mine had a 4K BASIC punchcard deck that ran on the DG Novas that ran our cardreaders at Cornell back in the mid-70's - if the IBM 370 was down, he could still work, sort of.
tihor@acf4.UUCP (Stephen Tihor) (03/14/85)
Recent proof was provided by the ADA/ED interpreter in Prolog yet. Just a technical correction but the NYU ADA/Ed system was originally implemented in SETL a very high level algorithmic language, not a logic language. Still not exactly a speed demon.
andrew@orca.UUCP (Andrew Klossner) (03/14/85)
I started to prepare a point-by-point rebuttal to this article. Then I
came to this paragraph:
"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."
Oh, yeah? Where were YOU when the call went out for people to
participate in the ANSI Basic committee? Where were YOU when the first
public review began in 1983, and the community was implored to comment
upon the draft standard? Where were YOU during the second public
review in 1984? Why are you only now, when the ten-year process is
complete, coming in to complain that you don't care for the result?
We deserve the government that we get, and the person who won't go to
the polls on election day has no business griping about the government.
The same principle applies to language standards. ANSI Basic is what
it is because of the people who cared enough to take the time and work
on it.
We recognize that ANSI Basic isn't perfect, but we're pretty damned
proud of it. I don't think any committee could have done better.
-- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP]
(orca!andrew.tektronix@csnet-relay) [ARPA]ndiamond@watdaisy.UUCP (Norman Diamond) (03/21/85)
> Oh, yeah? Where were YOU when the call went out for people to > participate in the ANSI Basic committee? Where were YOU when the first > public review began in 1983, and the community was implored to comment > upon the draft standard? Where were YOU during the second public > review in 1984? Why are you only now, when the ten-year process is > complete, coming in to complain that you don't care for the result? You weren't talking to me, but I know two answers. One applies to Basic, C, and Pascal; one applies to Fortran-77. Regarding Basic, C, and Pascal: When it was announced or otherwise known that a standard was going to be upgraded, how would I know that in fact, new languages were going to be developed but just given the old names? ANSI Basic is as close to "traditional" Basics as PL/I is to Fortran. C and Pascal are somewhat better, except for pre-processor stuff and tri-graphs in C. Now that we know, we complain. It may have been possible to predict what would happen, after seeing the results in Fortran-77. However, I have not needed Fortran very much during the last 7 years, and did not "learn" Fortran-77 until last year. A ton of stuff was added that does not belong in Fortran. If someone wanted to invent a new language with exactly that syntax for character strings etc., they should have done so; they should not have called it Fortran. I suppose that the next time I hear of a committee beginning to re-standardize a language, I will complain immediately that they're adding too many new features and/or mis-features, before I even know what they are. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
lambert@boring.UUCP (03/21/85)
> Where were YOU when the call went out for people to > participate in the ANSI Basic committee? Suppose a call goes out for a committee to decide on the color with which the housedoors in your neighbourhood are to be painted. This not quite being your kettle of fish, you don't participate. Now this committee decides that housedoors defigurate the neighbourhood and are unfriendly to a community spirit, and should be replaced by curtains. You complain. Would you accept the rebuttal: "Where were YOU ..."? Similarly, if the call is about standardizing an existing language, but the committee goes off and designs a new language that has everything the original language does not have ... -- Lambert Meertens ...!{seismo,philabs,decvax}!lambert@mcvax.UUCP CWI (Centre for Mathematics and Computer Science), Amsterdam
holtz@clan.UUCP (Neal Holtz) (03/24/85)
>> Oh, yeah? Where were YOU when the call went out for people to >> participate in the ANSI Basic committee? Where were YOU when the first >> public review began ... > > ... how would I know that in fact, > new languages were going to be developed but just given the old names? > ... Now that we know, we complain. > > ... and (I) did not "learn" Fortran-77 until last year. A ton > of stuff was added that does not belong in Fortran. If someone wanted to > invent a new language with exactly that syntax for character strings etc., > they should have done so; they should not have called it Fortran. Take this as a warning -- the changes proposed for Fortran-8X make the changes of Fortran-77 look minimal and insignificant. If the proposals are accepted, the next version of Fortran will be *MUCH* larger and a completely different language. It is legitimate to say that the various committees are inventing a new language (that is largely compatible with the old). Among the major changes are: array data types (sort of) and array operations; derived data types (i.e. records plus something akin to packages in Ada, complete with user-defined operators); internal and recursive procedures; modules; more "modern" control structures; event handling, and a fair bit more. I believe that ANSI Committee X3J3 will submit the proposal for public review sometime late this year. Everyone that cares about Fortran should give that document careful and thoughtful study. Until then, there are a few reports available. Some of them: [1] Wagener, J.L., "Status of Work Toward Revision of Programming Language Fortran", ACM SIGNUM Newsletter, Vol 19, No. 3, July 1984, pp 5-42. [2] Humar, J.L., "Fortran: Directions for the Future", National Lecture Tour, 1984, Canadian Society for Civil Engineering, Dept. of Civil Engineering, Ottawa, Ontario K1S 5B6. I may be able to provide a limited number of copies of [2] (no guarantee, though). Neal Holtz cdn: holtz@cascade.carleton.cdn uucp: ...dciem!nrcaero!clan!holtz csnet: holtz%cascade.carleton.cdn@ubc.csnet bitnet: holtz@carleton.bitnet
gast@ucla-cs.UUCP (03/30/85)
In article <160@clan.UUCP> holtz@clan.UUCP (Neal Holtz) writes: > >Take this as a warning -- the changes proposed for Fortran-8X make the >changes of Fortran-77 look minimal and insignificant. If the proposals >are accepted, the next version of Fortran will be *MUCH* larger and >a completely different language. It is legitimate to say that the >various committees are inventing a new language (that is largely >compatible with the old). > >Neal Holtz > [the above was edited] As the joke goes: They don't know what the language of the nineties will look like, but they know it will be called fortran. Have you ever compared FORTRAN I to FORTRAN IV? There is a huge difference. FORTRAN I did not have subroutines, etc; it did have several features which are no longer part of FORTRAN. There is also a huge difference between the language definitions of fortran, and the symbols that are accepted by fortran compliers. Many of the tricks 'real programmers' love are not fortran. david gast@ucla-cs