3 ms·

I vaguely recall there was an early-1980s microcomputer Forth that only supported 3-letter identifiers. You could use longer variable names if you wanted, but t

by pavlov 1y ago

I vaguely recall there was an early-1980s microcomputer Forth that only supported 3-letter identifiers. You could use longer variable names if you wanted, but the parser just silently truncated them, so "TYPE" and "TYPOGRAPHY" would both refer to "TYP" internally. This sounds like a very onerous limitation, so the company's ads had copy that consisted only of three-letter words, to make the case that it's not so bad after all... (I'm guessing the engine used four bytes to store a reference, and it needed one byte for other metadata.)

layer8 1y ago
Who would ever need more than 17576 identifiers, especially with the memory limitations of the time? ;)
drob518 1y ago
Forths created for constrained environments will sometimes use this sort of dictionary header structure, but it’s not just 3 characters. It also typically includes a length of the whole thing. So, TYPE would be TYP/4 (inventing a notation there) versus TYPOGRAPHY as TYP/10. While you can still get clashes, you’d be surprised how much better it does than a straight prefix. EDIT: Sorry, I realize I didn't explain that very well. A Forth system has a "dictionary" that stored the names of words (think procedures or functions) as well as their code. The dictionary is compressed like this (e.g., TYP/4 or TYP/10). When you're writing code, you write TYPE or TYPOGRAPHY in the code and the compiler searches the dictionary for either TYP/4 or TYP/10 depending on what you typed, ignoring the other one. Most of the time this works. If you have a bunch of words that are the same length with different suffixes, they will clash (e.g., AVGX and AVGY both reduce to AVG/4).
- pavlov 1y ago
  Thanks, that must be it. It makes sense as a very simple way to generate fixed 32-bit keys from words.
  - drob518 1y ago
    Exactly. It's a tradeoff between storage space and flexibility. Forths built for larger environments will store the whole string and won't worry about it. If you're a 32-bit Forth with GBs of memory in the system, it's no big deal. But remember that Forths are often used in 16-bit systems with KBs of memory (max 64 KB), so they're trying to be quite careful with each byte allocated. The fact that Forth can operate in such environments is what makes them popular for embedded programming.
- shakna 1y ago
  I wonder if adopting soundex for such a system would be more pleasant, for dealing with spelling mistakes, or worse, because of shadowing.
  - drob518 1y ago
    I think that would typically be worse. Lots of letters "sound the same" and get collapsed into a reduced number of distinct Soundex letters.
teo_zero 1y ago
> I vaguely recall there was an early-1980s microcomputer Forth that only supported 3-letter identifiers That's still one letter more than the earlier Microsoft BASIC ;)

by pavlov 1y ago

layer8 1y ago

Who would ever need more than 17576 identifiers, especially with the memory limitations of the time? ;)

drob518 1y ago

Forths created for constrained environments will sometimes use this sort of dictionary header structure, but it’s not just 3 characters. It also typically includes a length of the whole thing. So, TYPE would be TYP/4 (inventing a notation there) versus TYPOGRAPHY as TYP/10. While you can still get clashes, you’d be surprised how much better it does than a straight prefix. EDIT: Sorry, I realize I didn't explain that very well. A Forth system has a "dictionary" that stored the names of words (think procedures or functions) as well as their code. The dictionary is compressed like this (e.g., TYP/4 or TYP/10). When you're writing code, you write TYPE or TYPOGRAPHY in the code and the compiler searches the dictionary for either TYP/4 or TYP/10 depending on what you typed, ignoring the other one. Most of the time this works. If you have a bunch of words that are the same length with different suffixes, they will clash (e.g., AVGX and AVGY both reduce to AVG/4).

pavlov 1y ago
Thanks, that must be it. It makes sense as a very simple way to generate fixed 32-bit keys from words.
- drob518 1y ago
  Exactly. It's a tradeoff between storage space and flexibility. Forths built for larger environments will store the whole string and won't worry about it. If you're a 32-bit Forth with GBs of memory in the system, it's no big deal. But remember that Forths are often used in 16-bit systems with KBs of memory (max 64 KB), so they're trying to be quite careful with each byte allocated. The fact that Forth can operate in such environments is what makes them popular for embedded programming.
shakna 1y ago
I wonder if adopting soundex for such a system would be more pleasant, for dealing with spelling mistakes, or worse, because of shadowing.
- drob518 1y ago
  I think that would typically be worse. Lots of letters "sound the same" and get collapsed into a reduced number of distinct Soundex letters.

teo_zero 1y ago

> I vaguely recall there was an early-1980s microcomputer Forth that only supported 3-letter identifiers That's still one letter more than the earlier Microsoft BASIC ;)