Spaces in variable names

[equinox]

Spectrum BASIC is rather unusual in the fact that it allows you to put spaces in variable names. Furthermore, the spaces are not meaningful, so that the variable name with or without the space is equivalent. Thus:

10 LET pig dog = 12
20 PRINT pigdog

Please tell me:
1. Did you ever put spaces in your variable names? I certainly didn't.
2. Why do you think they implemented this? I don't think I've ever seen any other BASIC that does it, and I see no particular benefit. In fact it would seem to impede parsing, and thus possibly increase the size of the ROM.

[ParadigmShifter]

1. No.
2. No idea FORTRAN allowed you to put spaces in variable names (at least at first, they may have changed that nowadays). I think FORTRAN also allowed you to name variables after language keywords, lol. EDIT: 48K basic lets you do that as well though

It's more annoying not being able to use _ in variable names I think!

[equinox]

1. No.
2. No idea FORTRAN allowed you to put spaces in variable names (at least at first, they may have changed that nowadays). I think FORTRAN also allowed you to name variables after language keywords, lol.

It's more annoying not being able to use _ in variable names I think!

As it happens I am talking to ROM expert AOwen right now about the best way to tell a +2 from a +3. He said: "Spaces in variable names is just a side effect of the BASIC expression evaluation ignoring spaces." But then why does it get upset when I write CHR$a

Regarding the _ sign: when you got onto the PC, or I guess anything other than a home 8-bit, yeah, suddenly _ was the way to split your name, i_am_john_smith: but on the Spectrum this seemed to be an unusable symbol, as meaningless as @ or %. The whole concept of InterCaps or CamelCase didn't seem to exist then, or at least you never saw it in program listings (one point being the fact that every byte of the name was a byte, and short names saved memory).

[ParadigmShifter]

Aren't ZX Basic variables case insensitive as well? So Camel case is meaningless anyway...

[equinox]

Aren't ZX Basic variables case insensitive as well? So Camel case is meaningless anyway...

Well, sure, but it's helpful. I mean, "const" in C-like languages is meaningless (as far as readability goes), but it's there to warn us if we accidentally assign to something that shouldn't change.

...bad example because the compiler can enforce that one. Okay, fine.

LET psychotherapist=3
PRINT PsychoTheRapist

[ParadigmShifter]

const definitely isn't meaningless in C or C++, compiler can do otherwise unavailable optimisations. It's a massive pain in C++ as well since a const argument is part of the function signature (so you can provide 2 functions with the same name, one of which has a const argument and the other doesn't).

You can cast away constness though (which isn't guaranteed to work).

A compiler can put const variables into ROM for example if you are developing for cartridge etc.

[equinox]

const definitely isn't meaningless in C or C++, compiler can do otherwise unavailable optimisations. It's a massive pain in C++ as well since a const argument is part of the function signature (so you can provide 2 functions with the same name, one of which has a const argument and the other doesn't).

You can cast away constness though (which isn't guaranteed to work).

A compiler can put const variables into ROM for example if you are developing for cartridge etc.

Yeah I'm a moron. I really wrote "program correctness" where I meant "readability", which is the total opposite.
Don't worry, I've fixed it, so now your reply looks like nonsense. Hahaha.

[ParadigmShifter]

C++ allows you to put const in multiple places in the same declaration as well.

So

const char* const a; EDIT: I think that's right, may even be const char const* lol, C++ is a silly language - let's make an octopus by nailing 4 extra legs to a dog.

is a const pointer to const data.

That's quite useful and C# doesn't have that so a const reference does not mean the contents of the reference cannot change, just the reference can't. But then there's things like C# foreach where you can't change the contents of a container while you iterate over it. EDIT: I think you can try but it throws an exception if you do that?

[ParadigmShifter]

I thought I already answered Q2, "no idea". But you said it was done to make parsing easier so I guess you already explained that one.

EDIT: Ninja editing and post deletion makes my post seem meaningless again!

[AndyC]

I had no idea you could. But now I know you can do this I feel I may have to abuse the living daylights out of it in a CSSCGC entry or something. Spaces in variable names is madness.

[catmeows]

Please tell me:
2. Why do you think they implemented this? I don't think I've ever seen any other BASIC that does it, and I see no particular benefit. In fact it would seem to impede parsing, and thus possibly increase the size of the ROM.

Rather opposite, ROM uses single scan routine that skips white spaces. Side effect is that spaces (or color codes) are allowed within variable name.

[equinox]

Rather opposite, ROM uses single scan routine that skips white spaces. Side effect is that spaces (or color codes) are allowed within variable name.

Wow! It's true. They can't have designed this thing top-down, can they? But if you assign a variable a[green ink]b then it's the same as ab, or a[space]b. I still want to know why anyone thought it was a good idea. In the 1980s, you wanted to write a simple parser, with no nonsense.

I'm also interested in the switch from 48 to 128, where (for example) you suddenly couldn't call a variable "let" because that is a keyword — whereas 48 mode didn't care because LET was a separate token.

Well, I guess we just need to treat colourcodes as spaces (like catmeows said above). The question of WHY is outstanding.

[AndyC]

Rather opposite, ROM uses single scan routine that skips white spaces. Side effect is that spaces (or color codes) are allowed within variable name.

It probably makes the 128K parser horrific, but the single keyword entry system on the 48K basically exists to make input parsing less complicated (no matter how many justifications were used later to try and explain it as an end user benefit). When you don't really need to identify the ends of keywords, ignoring whitespace globally probably just makes more sense.

[equinox]

It probably makes the 128K parser horrific, but the single keyword entry system on the 48K basically exists to make input parsing less complicated (no matter how many justifications were used later to try and explain it as an end user benefit). When you don't really need to identify the ends of keywords, ignoring whitespace globally probably just makes more sense.

I was going to say "It doesn't globally ignore whitespace" but then I realised I couldn't think of a single counter-example.

So then you'd think "well AB is the name of a variable but A B is two things split by a space"; however, we know B isn't a token or a "print item" so it must necessarily be the other half of a variable...? Is it that simple? I still hate it.

[ParadigmShifter]

It's probably due to lots of the ROM being borrowed from the ZX81 code which only had single letter variable names I guess so could safely ignore whitespace? And when they added longer variable names it was just an interesting side effect?

[AndyC]

All the keywords are a single token, "parsed" at the point you type them in so those are all simple regardless of whether it is PRINT or GO SUB.

You need to skip over spaces, otherwise LET a = 5 would error because of the spaces (you'd end up having to enter it as LET a=5 which would feel very fussy).

Once you're skipping all the whitespace anyway it just becomes a natural extension to allow LET a b = 5 3 to be the same as LET ab=53 since you actually have to do additional work to prevent it.

[ParadigmShifter]

C already "did the right thing" which was greedily parse tokens (greedy so >> parses as a single operator rather then 2 greater than symbols) but delimit all tokens by whitespace if present.

[equinox]

you'd end up having to enter it as LET a=5 which would feel very fussy

did you know that Python was invented as a reaction against Spectrum BASIC?

[equinox]

C already "did the right thing"

To do the left thing, see K&R chapter 4, or Tumblr

[AndyC]

did you know that Python was invented as a reaction against Spectrum BASIC?

Python was invented by people who never had to code in VB6 and thus recreated it by accident, except worse.

Fact.

[1024MAK]

The ZX Spectrum ROM is a development of the ZX81 ROM. Which itself is a development of the ZX80 ROM. Which did have some functions that were typed in (no "single" keyword system for them)...

But back to the Speccy, it says this in the manual:

Numeric variables have names of arbitrary length, starting with a letter and continuing with letters and digits. Spaces and colour controls are ignored and all letters are converted to lower-case letters.

Mark

[Sokurah]

I wonder what happens if you do this;

10 LET pig = 10
20 LET dog = 20
30 PRINT pigdog

(easy to test, but I can't be bothered, lol)

[AndyC]

I'd expect a VARIABLE NOT FOUND error

[1024MAK]

Well, yes:

2 Variable not found, 30:1

Mark

[sn3j]

The system reads in characters through RST 24 and RST 32 - mostly RST 32 (GETNXT).
This is fetching HL from CH_ADD, reading a byte from HL+1 and testing the character code in this routine: https://skoolkid.github.io/rom/asm/007D.html

If the character is not printable, the Carry is set and GETNXT continues with the next character. Which means, any unprintable character will just be ignored by the interpreter (unless the interpreter faces a string, see below).

And unprintable in this regard includes the character Space.
In particular any character below and including Space will be ignored

• when the user inputs a line
• when a program line is being interpreted
• when VAL or VAL$ is evaluating the expression string

Strings are handled differently - that is, not by GETNXT - in that when an opening quotation mark is found, the closing mark is being searched by CP '"' and then the memory between start and end address processed.

So not only spaces will be ignored but also colour codes, or other control codes. Just try it out.
Reasons for this could be to be more forgiving to inputting glitches (where the user inadvertedly switched a colour), or to allow for spaces in VAL/VAL$ expressions.