ForthHub/discussion

Poll: preference of case-sensitivity

ruv opened this issue · 22 comments

ruv commented

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 commented

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

  • 👍7
  • 👎5
  • 🚀2
ruv commented

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

  • 👍6
  • 👎1
  • 🚀7
ruv commented

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

  • 👍3
  • 👎10
  • 🚀1
ruv commented

(D) a system should support case insensitivity in ASCII

  • 👍5
  • 👎1
  • 🚀6
ruv commented

(E) a system should support case insensitivity in Unicode

  • 👍1
  • 👎9
ruv commented

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

  • 👎8
ruv commented

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

  • 👎8
massung commented

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.

  • 👍3
  • 👎1
forthy42 commented

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.

  • 👍2
GarthWilson commented
  • ❤️1
mgcaret commented

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 commented

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 commented

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!

  • 👍1
massung commented

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.

TG9541 commented

Since users asked for it, STM8 eForth is case-insensitive by default but it can be configured to be case-sensitive, e.g. to reduce the binary size a bit. The docs therefore use upper-case core words.
👍 🚀

scherrey commented
paraplegic commented

My heritage, of C/Unix tells me that you specify what you want, so case sensitivity explicitly says what you want. The law of unintended consequences with respect to calls, links and various has bitten numerous times where an unintended link causes problems in a running system ... If case weren't important, then we wouldn't have two of them :-)

CCurl commented

IMHO, the system should be, by default case sensitive. But the option to be able to tell it to be case-insensitive would be really nice. I like the idea that it tries the case-sensitive search first, and if that fails, then try it case-insensitive.

crcx commented

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

I use case sensitive only. In my system, I use differing case to provide a visual feedback on what words are:

word-names  are lowercase
VariableNames  are titlecase
CONSTANTS are uppercase
mitra42 commented

My preference is for case sensitivity - which I'm used to in other languages I work in - foobar is not the same as FooBar .

I certainly disagree strongly with @scherrey and @massung :-) . IMHO standard words should be UPPER CASE and user-defined (non standard) should use lower, or mixed case.

GeraldWodni commented

tl;dr: Forth has extendable syntax, therefor case matters less than in other languages.

Typical Forth programs (written after gaining some experience in Forth; also what most books will teach you) will create a domain specific language to solve the task at hand. This differs a lot from other common languages where it is difficult to impossible to extend the syntax of the language itself.

When I started Forth I was strongly opposed to being case-insensitive as I was so used to case-sensitivity from all the other languages I knew. But the more I used it and saw code being written by others (remember to read other people's code to better yourself, not only reflect upon your own experience and force it on Forth), the more I became to see Forth more like SQL (bad example, cannot think of a closer one), where you can use the case if you want to emphasize.

Forth reads very differently because of its ability to change the syntax, you want a private word? in python you might go _soopersecret in Forth (soopersecret) looks much cleaner. You are not limited to alphanumerical Characters and a handful of punctuations in Forth, use-(what/how)-you_LIKE-to-name-your_#words.

That all being said IMO systems should be case-insensitive by default and have the option to change that preferably on a wordlist bases - FFIs and especially C being the obvious reasons for that. This is what most common systems do since ages.

phillipeaton commented

I converted my instance of Camel Forth to be case insensitive as it was driving me insane having to re-enter failed commands. I don't think having the ability to name two different things with pretty much the same name is as advantageous as not having to re-enter commands.