[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Integer BASIC's "*** NO END ERR"
- Subject: Re: Integer BASIC's "*** NO END ERR"
- From: Paul Schlyter <pausch@NOSPAMsaaf.se>
- Date: Sun, 26 Jun 2005 20:36:40 +0200
- Newsgroups: comp.sys.apple2
- References: <d9k9j5$i6h$1@ottoman.cs.fiu.edu> <2xkve.2045$p%3.14733@typhoon.sonic.net>
- User-agent: MicroPlanet-Gravity/2.70.2067
- Xref: g2news1.google.com comp.sys.apple2:12480
In article <2xkve.2045$p%3.14733@typhoon.sonic.net>, dakidd@sonic.net
says...
>In article <d9k9j5$i6h$1@ottoman.cs.fiu.edu>,
> Zorin the Lynx <yakko@zorin.org> wrote:
>
>> Ya know, I've always wondered why an END statement was required in
>> Integer BASIC programs on the Apple II. And if you didn't put one in,
>> you got the "NO END ERR" message.
>>
>> Why not just exit quietly when the program finished? The "NO END ERR"
>> message wasted valuable ROM space, and had no useful function.
>>
>> Anyone have any insight as to why Woz put this seemingly useless error
>> into INTBASIC? Did he just have extra space and wanted to fill it with
>> something?
>>
>> -Z
>
>Seems to me that Integer was (comparatively) brain-dead when it came to
>figuring out where program code left off and variable storage began.
A braindead Basic interpreter, unable to determine where the BASIC
program ended, wouldn't issue an error diagnose over a missing END
statement. Instead just continune past the end of the program,
trying to interpret whatever garbage happening to reside there as
BASIC tokens, with a program crash as the most likely result.
Actually you ARE supposed to put an END in your BASIC program when it
is about to end. But as we all know, sloppy programming quickly became
the norm among BASIC programmers. And they got support for that from
e.g. Microsoft's BASIC interpreters, which accepted never-END'ing BASIC
programs.
Integer Basic was intelligent enough to figure out that the END
statement was missing, and issue a correct error diagnose. Integer
Basic was actually a smarter interpreter than Applesoft Basic. Yes,
the syntax of Integer Basic was more limited, but within those syntax
limits, Integer Basic was smarter. Integer Basic would not allow a
stupidity like e.g. this:
100 IF A >=< B THEN <some statement>
This Applesoft happily swallows (since one numeric value always is
less than, equal to, or greater than another numeric value, the
condition in this IF statement always evaluates to "true", and the IF
statement itself can be rmoved - it does nothing useful).
---------------------------------------------------------------------
You must put an end to programs in other programming languages too.
If you omit the final END from a Pascal or FORTRAN program, or the
final closing brace from a C, C++, Java or C# program, the compilers
will treat this as a compilation error, forcing you to add the
missing END (or final closing brace), and recompile.
Do you consider Pascal, FORTRAN, C, C++, Java and C# "braindead" too,
just because they won't accept a source file with a missing END (or
final closing brace) ????
UCSD Pascal is really picky here -- after the final "END." you're not
allowed to put even an end-of-line. That final "END." must really
be last in the program - not even whitespace is allowed afterwards.
This is implemented in Apple Pascal..... the other languages are more
reasonable, and allow you to put as much whitespace as you want
after the final END (or final closing brace).
--
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se
WWW: http://stjarnhimlen.se/