Poll: preference of case-sensitivity about discussion

[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;

[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!

[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.

[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.

[TG9541]

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]

A) forth should be case sensitive and normal forth words should be lower case. We don't live in an age where systems were primarily limited to upper case letters all the time any longer.

…

On Tue, Mar 10, 2020, 6:08 AM ruv ***@***.***> wrote: Let's gather statistics of our preferences regarding case-sensitivity <https://en.wikipedia.org/wiki/Case_sensitivity> on finding definition names <https://forth-standard.org/standard/usage#subsection.3.4.2>. Each option will be posted consequently as a separate message. Voting is based on the GitHub build-in reactions <https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/> . 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 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; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85?email_source=notifications&email_token=AAGWP7ZK6UDU3U6PQARL343RGVZHFA5CNFSM4LETGBS2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ITXIADQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGWP77BHR4MQEX4WWQVFOTRGVZHFANCNFSM4LETGBSQ> .

[paraplegic]

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]

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]

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]

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]

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]

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.