Discussion on answer by Raffzahn: Why did BASIC programs tend to READ a redundant copy of DATA?

Feeds

17:28

8

A: Why did BASIC programs tend to READ a redundant copy of DATA?

TL;DR: Simple answer: Because it's the way BASIC is defined. Original BASIC had no way to access files at all. DATA lines were the only way to add predefined data to a program. The idea was essentially to have a stack of items - originally only numbers, strings where only added way later - that c...

TeaRex

Raffzahn, ad *5: Microsoft BASIC for the 6502 in fact does take this "special" approach - for string data. READing strings from DATA statements into string variables, whether normal or array variables, stores only the length and a pointer to the actual string. The only copy of the actual string content in RAM will be the one in the DATA statement itself. Only numerical data is actually copied, as of course a numerical variable stores a binary (floating point or integer) representation, while the DATA statement stores a string of digits.

I didn't notice that @supercat already says so in the next answer.

JDługosz

How can DATA be a "special" read-only array, when it can have mixed types (numbers and strings)?

Raffzahn

@JDługosz Well, isn't that already special? But serious, who say it has to be typed? The content of that array is input data, and like all input data it gets only typed when read into a (typed) variable. Isn't it?

@TeaRex True, I should have added a *5.1 for the fact that MS is doing it in part for strings like described in the next paragraph after were the footnote is placed.

JDługosz

I recall in BASIC that an array was an array of numbers or (if named with $) an array of strings. Likewise ordinary variables: they could only hold the right type based on their type. The DATA representation in the program cannot be like that of an array (DIM'ed variable).

Raffzahn

@JDługosz Cool, so if using 'special' to say that it's not an ordinary array doesn't satisfy your need for description, how would you call a data structure that is in a fixed, one dimensional sequential order and can be accessed as such?

JDługosz

17:28

When you said it was a special array, in context, I thought the point was that it's already using the same kind of internal representation as the array variable. IAC, the DATA is not indexable, can only be read sequentially. Being heterogeneous, I suspect it can't be indexed at all, but is read by scanning forward using either a type prefix or delimiters.

Raffzahn

@JDługosz Of course it isn't a conventional BASIC array - after all, then it wouldn't need to be read into such, or would it? This is about describing the logical structure behind, isn't it? So again what's wrong with calling sequential structure of elements an array, and what would be a better (still handy) term?

JDługosz

I'm referring to the paragraph in the post. You seem to be saying that DATA is already an array, meaning, in context, already what you get from the result of reading them into an array variable. Meanwhile, it's not an array in the more general sense, and the exact terminology varies by language, but the best description that doesn't rely on specifics would be "ordered heterogeneous list". list is normally the word I'd use, but now Python uses that for its array-like container, so not universally understood.

Raffzahn

@JDługosz Sorry, but you lost me with that comment.

supercat

On some platforms, especially the Commodore, it was common to use read/data loops to poke sequential bytes into memory. Read/data is pretty horrid for that, because it's slow, and because most data to be stored will end up taking 3-4 bytes of code space per byte of useful data. A "stuffhex" statement similar to the Classic Macintosh routine of the same name would have made things massively better, and also easier to program.

john_e

"Keep in mind that data that needs to be used need to be stored in source, so everything has to be present in source code anyway." - well, unless you're on a ZX81 or Spectrum where the contents of variables are saved with the program, so you can populate variables, delete the BASIC lines that populated them, and then save the program. Just remember to start it with GOTO rather than RUN...

scruss

17:28

Re note 3: BBC BASIC V5 and above already does inline definition of arrays. It starts from subscript zero, which is a bit odd. It's also (since V5 or so) treated arrays like matrices, so you can do array operations on them, just like Dartmouth and ANSI Full BASIC

Raffzahn

@scruss Sure. I haven't said it has not been done somewhere. I do in fact belive that evey idea on can have about BASIC has already been implemented in some version at some point by someone - heck, even I did my onw BASIC (extensions) in the 80s , like INC and DEC to get rid of the stupidly slow I=I+1. Further, I guess we all can agree that BBC BASIC is a quite good one, bringing many good parts to more people than most others did.

user46971

“DATA is already a read only array.” Well, except when using those clever utilities that POKE around in DATA strings in order to compress numeric values into single bytes. That's very platform-dependent, though.

supercat

@Raffzahn: I can imagine that INC and DEC could be a lot faster than using a floating-point add routine to add 1, especially if it checked for an exponent value of zero, or 64-79, added or subtracted a two-byte value from $0001 to $4000 (loaded from a table) to the top two bytes of the mantissa, checked for a change in the MSB, and if needed bumped the exponent and shifted the mantissa.

Raffzahn

@supercat yeah, that in addition, but just think about the savings of 3 less tokens to read and no need to convert ASCII 1 into float - and in case of integer skipping the float part at all. at least that's what I did. Small effort, considerable speedup.

supercat

@Raffzahn: Setting O=1 and then using X=X+O instead of X=X+1 would eliminate the decimal to float conversion, but adding 1 to a floating-point number is not a cheap operation. On a vintage C64, if one cranks up the volume and executes a FOR I=1 to 10000:NEXT loop, one will hear a whine that drops in pitch each time I's value reaches a power of 2.

Raffzahn

17:28

@supercat But still leaving the costly tokens and operations. Naa, I prefer to elimiate the cause, not reduce symptoms. So improving BASIC it was.

supercat

@Raffzahn: Token processing isn't instantaneous, and one may as well save that time, but I think the biggest improvements to be had patching BASIC would focus on reducing the time spent on numeric computations. Well-designed INC and DEC functions would do that in addition to saving time on token processing, and I suspect the FP time savings would represent a bigger portion of the performance benefit.

Transcript for

Discussion on answer by Raffzahn: Why…