Being case-insensitive for binding and equality comparisons makes Rebol/Red pretty unusual. It is certainly more costly in the implementation and harder to write. And it opens a huge can of worms to try and define what case insensitivity means at a system level...especially with UTF-8.
When I think about it, I've almost never used it (on purpose), and all it does is get in the way. (Admittedly I did for a time try typing
FAIL [...] in all caps to draw attention to it even though it was defined as
fail...however I found this ugly, and stopped doing it.)
Pretty much all of the reasons I cite in "Making the Case for Caselessness" could be covered just by a best practices document saying "don't use mixed-case names in your code, even though that seems to open up more unique space for identifiers". And you're done.
A Current Example of Caselessness "Getting In the Way"
I was trying to do some cleverness based on the idea of not redundantly storing the string in bound WORD!s...but just letting the name come out of the object it was bound to. This could reclaim one pointer per cell in bound words and would be extremely useful for something I am doing. (It's actually more than useful, it's probably critical to get that slot.)
But it had this Bad Effect (tm):
>> obj: make object! [Some-Name: 10] >> block: [some-name, some-other-name] >> bind block obj >> block == [Some-Name, some-other-name] ; ack, where'd my case go?!
That's obviously an unacceptable consequence. But when you think about it, you're not really far from having a similar "lossiness" just about anywhere in the system. It's super easy to look things up in tables and go "oh, it's there" and then fetch it back with it actually being different than what you put in.
A Losing Battle?
It's tempting to just punt on the whole thing and change the rules of the system to strip out all of the case-insensitivity. (I recall on a wiki about map case sensitivity, DocKimbel had said that if it weren't for historical compatibility with Rebol2 practices, he'd have probably wanted to make Red case-sensitive.)
So I wonder:
Is the case-insensitivity battle the right battle to be choosing, when it's different from basically all other current languages?
Is it even a winnable battle, if chosen?
It Doesn't Technically Have To Be All-Or-Nothing
The system today follows a fair number of hybridized rules. We could just bend it a bit and say that the BIND operations are based on
is) equality, and that
= still is case-insensitive.
However: this would lead to a world where
o: make object! [A: 10, a: 20] is an object with two distinct fields. So you'd presumably want
o/a to get those different fields. Hence some of these decisions seem tied together. Although we could say that
/ is case-insensitive for historical Rebol compatibility, while the
. operator is case-sensitive, which might be a nice compromise...?
That doesn't change the fact that in such a world--as always--you want a case sensitive and case-insensitive comparison. It's just a question of ('A is 'a) vs. ('A = 'a). And you're saying that pathing and binding lookup uses whichever version of that is case-sensitive.
Does Anyone Object to Case-Sensitive for Just Binding?
It's independent of what = thinks about case, that can be decided separately.
Best-practices could still recommend avoiding the use of mixed case or all-caps in object keys...saving it only for situations where one is trying to achieve compatibility with some external demand. So most people wouldn't notice a difference.
We might try making . accesses case sensitive and leaving / access case-insensitive (if that's seen as necessary? Is it? No reason to do it if no one actually thinks this is important...and they can focus on more interesting distinctions.)