3 ms·

Forths created for constrained environments will sometimes use this sort of dictionary header structure, but it’s not just 3 characters. It also typically inclu

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.

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.