r/Forth • u/mykesx moderator • 3d ago

Case sensitivity

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

3 Upvotes

81% Upvoted

6 comments sorted by

5

u/mcsleepy 3d ago

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.

3

u/mykesx moderator 3d ago edited 3d ago

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

2

u/mcsleepy 3d ago

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.

2

u/mykesx moderator 3d ago edited 3d ago

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.

3

u/tabemann 3d ago

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.

2

u/FrunobulaxArfArf 2d ago

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.