Re: How to detect EOFs in SEQ-files using M/C?

[Matthew Montchalin <mmontcha@OregonVOS.net>]

On Tue, 10 Sep 2002, Paul Schlyter wrote:
|>> From what I can vaguely recall, there was more than one kind of
|>> Applesoft Basic out there.  I think there was something called
|>> 'integer basic' that performed very well compared to floating point.
|>
|> Integer BASIC != Applesoft.  The former was limited to 16-bit integer math,
|> while the latter does single-precision floating point.  Applesoft also
|> allows character arrays; Integer BASIC doesn't.  OTOH, Integer BASIC was
|> supposed to be somewhat faster at some things...I guess that says something
|> about Steve Wozniak's coding skillz vs. Bill Gates' coding skillz. :-)
|
|Integer Basic used a much more complex tokenization of the Basic
|source (integer constants for instance were stored in binary form; a
|comma could be one of several different tokens depending on where it
|appeared,

Hmm.  That is very interesting!  Wouldn't that make the parser somewhat
larger than would otherwise be the case?

|etc etc) while Applesoft used a very simple-minded approach: reserved
|words were tokenized, spaces were removed except in string constants,
|and everything else were left as plain ASCII.

Hmmmmmmm....

|This meant that in e.g.:
|
|    FOR I=100 TO 1000 STEP 10
|
|Integer Basic stored the "10", "1000" and "100" in binary form, while
|Applesoft left then in ASCII form.

Okay, but how is the line number itself stored in memory?  Is the
line number itself stored as binary, as with Commodore BASIC 2.0?

|Which meant that Applesoft had to convert the ASCII string of digits to
|binary for each and every loop!

Shouldn't the binary be exported to a place in RAM, before the loop
is embarked upon?

|And Applesoft converted then to floating-point too!  Since Applesoft
|had no way to distinguish an integer constant from a floating-point
|constant....

Hmmm.  So a loop can be a lot bigger with Applesoft (because of
floating point) than with Integer Basic?