BASIC: Graphics characters in immediate mode

[rje 232]

In BASIC, $80-$FF are tokens.  And below that, they are themselves.  Including the graphics characters.  Right?  Can we make these lower printables DO things?

Type a batch of them on the command line and press <return>.  The interpreter gamely returns "READY."   No syntax error, because they simply exist.  They don't DO anything.

PI, on the other hand, represents something, so it will error out.  As will letters.

 

Sounds like something useful looking for a purpose.

LIKE WHAT?  Well how about variable characters?  What if you could use the heart character as a VARIABLE?  What if your valid variable set were larger than A-Z0-9?

"Who needs 16,000 two-letter variables?" you say.  "They collide with the way shortcut BASIC commands work."  Fine.  But these critters seem to me to be available for functionality of some kind.

 

Edited February 12 by rje

[DocCaliban 0]

On 2/11/2021 at 4:06 PM, rje said:

 Well how about variable characters?  What if you could use the heart character as a VARIABLE?  What if your valid variable set were larger than A-Z0-9?

 

Interesting...  I would like that same feature for modern languages as well.

I imagine that  using the following import statement in JavaScript would be appropriate.

import   from 'jquery';

[TomXP411 357]

On 2/11/2021 at 4:06 PM, rje said:

In BASIC, $80-$FF are tokens.  And below that, they are themselves.  Including the graphics characters.  Right?  Can we make these lower printables DO things?

Type a batch of them on the command line and press <return>.  The interpreter gamely returns "READY."   No syntax error, because they simply exist.  They don't DO anything.

PI, on the other hand, represents something, so it will error out.  As will letters.

 

Sounds like something useful looking for a purpose.

LIKE WHAT?  Well how about variable characters?  What if you could use the heart character as a VARIABLE?  What if your valid variable set were larger than A-Z0-9?

"Who needs 16,000 two-letter variables?" you say.  "They collide with the way shortcut BASIC commands work."  Fine.  But these critters seem to me to be available for functionality of some kind.

 

There are a ton of problems with that, starting with the strange way Commodore ASCII is designed. There's a whole duplicate set of text characters in the $C0-DA range, and when you press shift-A, you do not get character code 97. You get 193. I don't know why this is, but it bit me in the rear back in the 90s when I was trying to write a program to work with my modem... I had to hand-code certain bits of text with CHR$() functions to get the program to recognize the modem's messages. 

Anyway, setting that aside... it's bad style to design "Aa" and "AA" to be separate variables.

There is a standard in the professional community for casing: it's to note the scope of a variable. 
CONSTANT_VALUE = "Hello World"
public Word = "hello"  // any public class member or parameter passed into a function
private word="world"   // private or local value
public Say(string Text) // Say is capitalized because it's public. Text is capitalized because it's a parameter and always comes from outside the function. 
private whisper(string Text) // Text is still capitalized, because it's still from outside the function... whisper is lower case because it's a private function. 

Now that's not the only style rule out there - it's just the one I use. Different companies and languages have different expectations, but one thing generally holds true: don't use upper and lower case versions of names for different purposes. 

So while Hello and hello should never be used for different data, you might use the private variable as a backing store for the public accessor, like this:
public Name as string { 
    get { return this.name; }
    set { this.name = value; }
}

So... since BASIC is supposed to be a language for instruction, we don't want to teach bad habits early. Teaching people to use two-letter variable names is bad enough, and IMO that really needs to change. But trying to deal with variable names like T↖ would be nuts.

Also, ANSI BASIC does not care about variable case. Microsoft BASIC-80 and Advanced BASIC both force all symbols to upper case, and other legacy interpreters either force upper case, ignore case entirely, or fail with lower case letters. There are some modern interpreters where case matters... but those aren't entirely "BASIC" and are often not ANSI compatible anyway.

So it would be a better choice to extend the variable names and improve the hashing and lookup of names, than to introduce distinct upper and lower case identifiers. My personal preference would be to create a name table, where the variable names are defined once. Then tokenize the variable names with a 3 byte token sequence: something like $05 for "variable" and a 16-bit index into the table. 

 

Edited February 27 by TomXP411

[rje 232]

I'm on board with that, Tom, but I wasn't thinking about case.

 

Edited February 27 by rje

[TomXP411 357]

On 2/27/2021 at 7:40 AM, rje said:

I'm on board with that, Tom, but I wasn't thinking about case.

 

You specifically mentioned the heart character, which is a shifted S. Also, since the CBM-shifted characters are above 128 (and, as you mention, overlap BASIC tokens), we can’t use those. 

So you were thinking about case, even if you didn’t realize it. 

Edited February 28 by TomXP411

[rje 232]

22 hours ago, TomXP411 said:

You specifically mentioned the heart character, which is a shifted S. Also, since the CBM-shifted characters are above 128 (and, as you mention, overlap BASIC tokens), we can’t use those. 

So you were thinking about case, even if you didn’t realize it. 

Ahhhhh yes.  Mph.