Making the Case for Caselessness


#1

Rebol has two major areas of case-insensitivity by default. One is in binding, so variable naming and function names are handled case-insensitively. The other is in general treatment of data…so routines like FIND, etc.

Historically data case-insensitivity has applied to = / equal? as well. Ren-C plans to undo that particular choice, with the IS and ISN’T proposal. The “wordish” IS would fall under the case-insensitive operation of the “wordish” operations like FIND, while the “mathish” = would align with the stricter expectations that programmers would expect out of an equal sign.

I’m moving ahead with this for Beta/One…and have to say it’s looking rather good so far. I think that I underestimated how easily we scan English phrases like method is 'script as infix and meaningful…it reads more comfortably than I expected. I even thought of a way to emphasize the case insensitivity when comparing to a literal: use mixed case for the thing on the right. So method is 'Script.

But doing the changes, I also realize how many instances were using = because it’s prettier and easier to type than ==…when strict equality was actually what was intended (or would be preferred). It’s chronic…and for instance, nearly 100% of the tests in the test suite which used an = meant to use ==…with the only exceptions being those few tests that were specifically designed to test lax equality.

But if I’m noticing how frequently one meant == when one had said =, what is the essential difference between:

 [a b] = compose [a () b]
 did find [[a b] [c d]] [a b]

If these were tests, both would prefer case sensitivity, wouldn’t they?

This raises the spectre of the old “why case-insensitive at all?” debate

That debate has been opened, looked at, and closed several times already. It’s no longer on the table.

Still, when a decision bucks the trend of basically every mainstream language in such a big way, there should probably be a coherent defense somewhere to point people to. So I collected my thoughts together here in a blog:

http://blog.hostilefork.com/making-the-case-for-caselessness/

As far as I know, that is the best single-document argument made to date on the topic. If you want to submit addendums or corrections, comment on the source on GitHub

So IS and ISN’T tweak a couple of operators, THAT’S IT

(…although I’ve mentioned it’s not likely that <fOo> is "FoO" will be true. The type mismatch is a difference that goes beyond case.)

This is not a referendum on case insensitivity in the language. All this is doing is changing english-word operators to line up with the language’s lax default, and lets symbols like = provide a stronger rule, as the exceptions since they are mathy.

I’m looking forward to seeing == die off in equality, and be used for other purposes in code. I’ve imagined it as a MarkDown-like construct, for doing conditional debug output. The number of = signs used could indicate the verbosity level at which the message might be printed, and it could be variadic to gather the arguments between marks, to feed into a PRINT statement.

 == {Main Loop} ==
 // ^-- e.g. prints if verbosity = 1

 repeat n 100 [
     === {Process Item} n ===
     // ^-- e.g. prints if verbosity = 2
     ...
 ]

I think it’s going to be a great change.