Poll: preference of case-sensitivity

[ruv]

Let's gather statistics of our preferences regarding case-sensitivity on finding definition names.

Each option will be posted consequently as a separate message.
Voting is based on the GitHub build-in reactions.

Please use the following reactions to vote:

• 👍 +1 — I need this option (as a user).
• 👎 -1 — I don't want to provide this option (as a Forth system implementer).
• 🚀 rocket — I already provide this option in my system (as a Forth system implementer).

---

The question is: What is your preferred options regarding case-sensitivity for definition names resolving?

Any number of the options can be marked.

The options are:

• (A) by default (initially) a system should be case sensitive;
• (B) by default (initially) a system should be case insensitive;
• (C) a system should have ability to turn on/off case sensitivity;
• (D) a system should support case insensitivity in ASCII;
• (E) a system should support case insensitivity in Unicode;
• (F) a system should provide a hybrid case-sensitivity mode: if exact match is not found, try to find in case insensitive mode;
• (G) a system should provide a hybrid case-sensitivity mode: if exact match is not found, try to find the name in upper case;

You can also add other options (as separate messages too).

[ruv]

(A) by default (initially) a system should be case sensitive

[ruv]

(B) by default (initially) a system should be case insensitive

[ruv]

(C) a system should have ability to turn on/off case sensitivity

[ruv]

(D) a system should support case insensitivity in ASCII

[ruv]

(E) a system should support case insensitivity in Unicode

[ruv]

(F) a system should provide a hybrid case-sensitivity mode: if exact match is not found, try to find in case insensitive mode

[ruv]

(G) a system should provide a hybrid case-sensitivity mode: if exact match is not found, try to find the name in upper case

[massung]

So, not an above, but my choice is:

(H) It doesn't matter, but the documentation should likely adhere to certain "standards". If the documentation is referencing words in ALLCAPS, then it's case-insensitive. If implementation is case-sensitive, then all core words should be lowercase where it's reasonable to do so.

[forthy42]

Gforth has case sensitive wordlists and vocabularies, if you need those. Most common this is used for C bindings, because C is a case sensitive language.

[GarthWilson]

I guess I sent this to the wrong email address the first time. I will go for A and C.  I want case-sensitivity, but I also think choice is good.  The Forth I 'grew up' with had for example do (the internal) compiled by DO (the immediate, compile-only word), loop (the internal) compiled by LOOP (the immediate, compile-only word), etc.. I know many will disagree with me (which is why choice is good), and it may be like arguing over whose favorite color is best; but In prose, the lines on the page exist because a book is more manageable than a mile-long ribbon with a lump here and there for pictures.  In programming however, the separation into lines becomes very significant for visual factoring, and having ascenders and descenders (as lower-case does) blurs those divisions.  Similarly, numerals 0-9 are always "capitals."  Do not mix lower-case a-f into them in hEx nUmBErS!  Write for example 3FA9, not 3fa9.  On more than one forum I'm on where the non-code sections are in proportional spacing, when someone writes for example 3fff, in whatever font is used here, it initially looks like 3111 to me because the f's are so narrow.  It's no harder to type capitals with the caps lock on. (I do take it off for comments.)  If you feel like the computer is yelling at you, then turn the font size down.  Easy enough. On 3/9/20 4:08 PM, ruv wrote: [...] (A) by default (initially) a system should be case sensitive; (B) by default (initially) a system should be case insensitive; (C) a system should have ability to turn on/off case sensitivity; (D) a system should support case insensitivity in ASCII only; (E) a system should support case insensitivity in Unicode; (F) a system should provide a hybrid case-sensitivity mode: if exact match is not found, try to find in case insensitive mode; (G) a system should provide a hybrid case-sensitivity mode: if exact match is not found, try to find the name in upper case;

[mgcaret]

For OF816 I chose to be tied to Open Firmware's specification, so I am stuck with case-insensitivity (which I prefer).

It's certainly not the only way to do things, and I made it open source so if someone wants to make a case-sensitive fork, they can. The great thing about all the Forths out there is that you can either find one you like, bend one to your will, or write your own if the former options don't work.

[MitchBradley]

My forth systems are all configurable. I prefer insensitive because I think that people are bad at remembering the details of capitalization, different natural languages have different capitalization rules, natural language words that differ only in capitalization are usually (with a few exceptions) either not considered different or people don't treat them as different in practice, and capitalization differences are hard to convey verbally. It is just a recipe for confusion to have two different identifies that are spelled the same except for case. Also, think about how tedious it is to tell someone a WiFi password with mixed case. You have to stop all the time to say capital this, lower case that, etc.

[howerj]

I thought one of the main the ideas of Forth was simplicity, and simplicity of it's implementation, as such I never understood why Forth had case insensitivity at all. It is an extra piece of complexity. Some people may like insensitivity, others may not. What is not undeniable is that extra complexity no matter how tiny.

As such, I'm voting for A:

(A) by default (initially) a system should be case sensitive;

But only because that best approximates what I think is best.

Option (E) does not even make sense!

[massung]

I never understood why Forth had case insensitivity at all

When working with an FFI, case-sensitivity matters. And unless you want to try and come up with alternate names for foreign functions that are case-insensitive, you need it.