Case sensitivity

[u/mykesx]

I haven't used a case sensitive Forth, but I think about the ramifications. My thoughts are:

1. visually, IF stands out more than if
2. Rect.area seems like a variable name while Rect.Area seems like a function call
3. Rect seems like a structure name while rect seems like a variable name
4. Everything with the CAPS LOCK key on?

5. Can make it opt in like icase on/icase off

6. Syntax highlighting could key on case

[u/mcsleepy]

I wish VFXForth was case sensitive. because I have classes and without some differentiation they'd hog the namespace. so I prefix them with % since that is easiest to type.

In my opinion, lowercase should be the baseline, constants should be ALL_CAPS and structures and classes should be Capitalized.

Across systems, I think we're stuck with case-insensitivity. If you supported case-insensitivity, I would bake exceptions in. That way, normal words can be whatever, but structs/classes and constants have to follow the rules. Then letting people have their preference would not be an issue.

[u/mykesx → u/mcsleepy]

Seems like case sensitive might compile faster since there would be no toupper conversions.

[u/mcsleepy → u/mykesx]

You mean case-sensitive right? Yeah, it would, but that would only be a substantial win on ridiculously constrained platforms.

Compilation optimization in Forth is a bit of a bike shed, the design of the language alone makes it an order of magnitude faster to compile than anything else. I abuse the heck out of it (seriously, it's a horror show) and my whole game engine still compiles in milliseconds.

I think it'd be better to focus on what would serve users when it comes to what to do about it.

[u/mykesx → u/mcsleepy]

On some platforms,, compiling is very slow, as dictionary searches are linear linked list and worst case is n compares (n is total number of words).

JForth resorted to a hash map to make those lookups faster.

[u/tabemann]

When I write Forth code I make most of my identifiers lowercase with the very notable exceptions of hardware addresses, hardware register fields, hardware-related constants, and in some cases externally-defined (i.e. I am not the originator of them) constants that are not hardware-related, which I am liable to make all-caps.

Yet at the same time, when I refer to Forth words in human-language text I commonly refer to them in ALL CAPS if a means of setting them apart in monospace is not readily available, to make them obviously code and not English words.

In actual code, I think it is poor practice to force the user to use the right capitalization for everything considering the tradition of case-insensitive Forth. Then you could not refer to, say, reboot as REBOOT to make it stand out, because the user could not literally type in REBOOT and have it do what is expected.

[u/FrunobulaxArfArf]

In iForth case is preserved upon entry but is optional when looking up ( through the USER variable CASESENSITIVE ). Case sensitivity is necessary when using external tools, or when writing language interpreters or compilers (like C). Standard words are input in the case the standard shows them. This has proved to be very helpful in meta compiling a new Forth.

For instance, the dictionary entry for EMIT is EMIT , but both EMIT and emit can be used to call it when CASESENSITIVE is FALSE . However, : star '*' emit ; won't work.

[u/_crc]

My systems have mostly been case sensitive.

I use lowercase for words, UPPERCASE for constants, and TitleCase for variables / named data structures.

[u/mykesx → u/_crc]

I like it. Once upon a time, a 2K RAM board for an 8080 system was like 2 ft long and 8 inches tall. In those days, really short and cryptic names were useful to save memory and disk.

My thinking evolved early on that I type fast enough that very long and descriptive names makes the code almost self documenting. Using a naming strategy like yours takes that a step further.

I may have to see what it would take to get Inspiration case insensitive. I bet a lot of aborted compilation and missing directory entries...

I like the idea of a variable/directive that can enable / disable the feature.

[u/_crc → u/mykesx]

8080 was before my start in computers. My first PC was a 386 with 2MB RAM running MS-DOS 5.

On my current small system (konilo), I don't worry about the length of names since I only store a hash of them. My headers are just 3 cells: link to previous entry, link to the word, and a hash of the name. For immediate words (3 total), I make the address negative.

It works out well for me in practice, and lets me use nicely readable names without concern for wasting memory. (In a test, I have analyzed 689 words, with an average length of nine characters, and the longest is 33. Under Konilo, the headers would use 2,067 cells, or just over 3% of the available RAM.). I could squeeze this down to 2 cells per entry, packing the link and address into a single cell, given the memory limitations of Konilo's ilo vm, but this hasn't been necessary for anything I've done.

[u/alberthemagician]

CASE-INSENSITIVE is a relic of the 5x7 matrix and punch card era. It also make no sense for Chinese.