5 ms·

Lisp isn't actually case insensitive. The reader is case-folding by default. You can set your READTABLE-CASE to change this: http://clhs.lisp.se/Body/26_glo_c

• kazinator 8y ago
  That depends on Lisp dialect; the above is true for ANSI Common Lisp. Scheme is basically case sensitive. R5RS was insensitive; they repented from the idiocy and made R6RS sensitive. Finally, they caved in and made it configurable. Emacs Lisp is insensitive; FOO and foo are different symbols. TXR Lisp, ditto. Case insensitivity is arbitrarily stupid; you're taking two subranges of a character set and making them equal. It ignores the fact that there are semantic differences linked to case: like Pole is someone from Poland, whereas pole is one end of a magnet. I see foo and Foo as completely different; I've been programming in C and using Unix file systems for thirty years. Case insensitivity is complicated in Unicode. To be implemented correctly, it must handle every script that exhibits a case-like duality or plurality whereby the same sounds are encoded with multiple sets of related glyphs: CLISP fails here: [1]> (eq 'ångstrom 'Ångstrom) T [2]> (eq 'フバル 'ふばる) NIL How about SBCL and others? If you make things completely insensitive so that different codepoints are different characters, you don't have to implement reams and reams of tables for handling all of the scripts. There are other issues there, like similarities between glyphs and groups of glyphs that aren't in a case-like relationship. These are worse than case, even; we can have a symbol ffi that is a ligature, and one that is just the three ASCII letters. We don't even have to go to Unicode to find visual confusion issues: should we fold together 1 and l so that someoone doesn't name different variables poll and po11? These two look more similar to me than B and b, or E and e. In some typefaces it's worse than in others. People have exploited this sort of thing in obtaining vanity license plates that are hard to transcribe correctly for police officers. All sorts of language features can be abused. We can have nested scopes such that an identifier can have different bindings in the same apparent scope. We don't need foo and Foo to create confusion: we can just have nested let-s with foo present at different levels of nesting. Should that be banned? Basically, the right guiding principle is to trust the users of programming languages to be grownups. By the way, in a number of mainstream functional languages, FooBar would be a type and fooBar a value, enforced at the language level. That is monumentally idiotic; you basically have case sensitivity and the implementation still has to recognize case distinctions. If we use Japanese names in Haskell, which is the type: the one starting with katakana or the hiragana one? How do you use scripts that don't exhibit case?
  • ken 8y ago
    > Case insensitivity is arbitrarily stupid; you're taking two subranges of a character set and making them equal. I think this is backwards. Languages are top-down, and character sets are bottom-up. A language can reasonably choose to use the common concept of "the 26 English letters (ignoring case)". This would require dealing with such implementation details as "subranges of character sets" only because that's the platform that computers today present. It's not unique to characters. Many programming languages say that 2 is equal to 2.0 (and 2/1 and (2,0) and ...), even though their internal bit patterns are usually completely different. We simply decided that this is the semantic meaning that we wish to expose to users, and the implementor has to work out how to deal with IEEE FP and such. > It ignores the fact that there are semantic differences linked to case: like Pole is someone from Poland, whereas pole is one end of a magnet. There are also semantic differences from context and from pronunciation -- English is pretty stupid -- but I don't think anyone would suggest appending every identifier in a program with a pronunciation key, or the OED meaning. Just because a word without capitalization can be ambiguous doesn't mean a word with its capitalization is unambiguous, or even that this would be desirable if it were.
    • cryptonector 8y ago
      Case-insensitivity is annoying to me, and much more difficult to implement than case-sensitivity. Yes, yes, one should always implement Unicode normalization or at least form-insensitive comparisons, but that's a subtly different. Even if you implement normalization / form-insensitivity, case-insensitivity still requires significantly more constant data tables. And you really have to have normalization support if you're going to do case-insensitivity.
      • deleted 8y ago
        [deleted]
  • viraptor 8y ago
    > If we use Japanese names in Haskell, which is the type: the one starting with katakana or the hiragana one? That sounds like the wrong question to ask. Neither script has uppercase, and you're not mixing them in a word. A better question would be: should scripts without case support be valid Haskell identifiers to begin with.