What's wrong with this line here?

[Wertzui]

I'm was looking to see if my usual BASIC program I try on everything would work on the X16 emulator too.

(I was thinking the <> operator is at fault here)

[JimmyDansbo]

Quote

TI$ and DA$ (DATE$) are now connected to the new date/time API

That is from Release 37 of the ROM

https://github.com/commanderx16/x16-rom/blob/master/README.md

[Wertzui]

Now I noticed It's the DASH$ variable it has problem with.

[SlithyMatt]

I don't think string variables can be larger that 2 letters before the $. Change it to DA$ and that will probably fix it.

[Wertzui]

Never mind, renaming DASH$ to D4SH$ did the trick.

But what is DA$ used for by the system?

[Wertzui]

@SlithyMatt

String variables can be larger than 2 letters, just the letters above the first 2 won't make a difference. I usually write then out to know what they're about.

[SlithyMatt]

Ok, so try DH$ or something, and that should get rid of the conflict. Good catch, @JimmyDansbo!

[Wertzui]

@JimmyDansbo Great. Less free variable names to use.

[Michael Parson]

It's a hold-over from the C-64 BASIC that they started with.  With all the C= 8-bit BASICs, while variable names could be longer than 2 characters, they were only unique for the first two characters of the variable name, so if you tried to set up variables BOB, BOTTLE, & BOING, they'd all be (internally to BASIC) "BO".  There are a few reserved variables for system use.  TIme, TIme$, STatus, and now with the X-16, DAte$

10 BOB=10
20 BOTTLE=20
30 BOING=30
40 PRINT BOB,BOTTLE,BOING
RUN
 30        30        30

In any case, yeah, our variable namespace has shrunk by one with the X-16 from what we had on the C-64.

[Wertzui]

Coming from QBASIC, I consider the 2-letter variable name space (and no numbers in the first spot, remember) to be a pretty harsh limitation. In some cases even it conflicts when the variable name resebles a BASIC keyword.

[rje]

29 minutes ago, Wertzui said:

Coming from QBASIC, I consider the 2-letter variable name space (and no numbers in the first spot, remember) to be a pretty harsh limitation. In some cases even it conflicts when the variable name resembles a BASIC keyword.

You're right on both counts.

1. It's harsh
2. It can conflict with BASIC, in which case a syntax error is generated
3. It can conflict with reserved variables, similarly to #2.

[TomXP411]

3 hours ago, Wertzui said:

Coming from QBASIC, I consider the 2-letter variable name space (and no numbers in the first spot, remember) to be a pretty harsh limitation. In some cases even it conflicts when the variable name resebles a BASIC keyword.

It probably has to do with the way variable names are stored. I haven't dug into MS BASIC, but I can make some guesses. 

Let's start with how variables work: the interpreter has to associate a letter/number sequence (A, B3, NAME) with a location in memory. So somewhere in memory, the interpreter needs to create a name table and have a quick way to search that table. 

Let's start with the simplest name table: single character names. Names like "A" and "F" can simply be stored in a single list. So the variable "A" would be index 0 on the list, and "F" would be index 5. This is super easy to look up, as all the interpreter needs to do is subtract 65 from the variable name, then look at that position on the list. 

But now we add two letter variables to the mix, and we need a way to associate the names with the location in memory. We also need a quick way to look them up. So let's look at how MS BASIC does so:

I created a simple BASIC program that sets A=1, B=2, and AB=3

On the Commodore 64, variables are stored at (VARTAB), where each variable uses 7 bytes of memory. Let's take a quick look in there:

VARTAB is located at 2D on the Commodore 64, and it is a pointer, which points to $081C. 

If we break this down 7 bytes at a time, we get:

41 00 81 00 00 00 00
42 00 82 00 00 00 00
41 42 82 40 00 00 00

So we see that the first two bytes of each variable block are the name. $41 is ASCII A. $42 is ASCII B. And obviously $41 42 is AB. I won't go into the binary float representation of the values, other than pointing out that the 5 bytes after the variable name are the value. (And those do match up with the floating point values for 1, 2, and 3.)

When a variable has a sigil ($ or %), that is stored by adding $80 to the first byte of the name for integers (%) and the second byte for strings ($).

So how does BASIC look these variables up? You'd think the interpreter uses something fancy, like a binary sorted list, or maybe a hash table. 

Nope. 

Consider this:

The variables are not sorted and are not in name order. So it's likely that the BASIC interpreter just does a linear search to locate a variable name. 

So BASIC 2 is really not capable of longer variable names, nor is it particularly efficient when the list of variables gets longer. 

My current solution is to keep a table of variable names, based on a simple rule set:

1. Use the first to letter: Hello > HE
2. Use the first letter and the last letter: Helicopter > HR
3. Use the first letter and one in the sequence (0-9,A-Z) : Hammer > H1, Horse > H2

I have actually written a simple code editor and converter that takes BASIC-like code and re-writes variable names and line numbers. I'm currently working on adding abstractions like functions and WHILE loops... and it will hopefully eventually be self-hosted, so you can run the entire thing directly on the Commander. 

Edited March 3, 2021 by TomXP411