4 ms·

I'll go ahead and voice some support. My position isn't as extreme, but I do think that case-sensitivity is overused and should not be the default. There are pl

by lmkg 8y ago

I'll go ahead and voice some support. My position isn't as extreme, but I do think that case-sensitivity is overused and should not be the default. There are places where it makes sense and should be used, but not many compared to how much it's used in the wild. This is especially true for programming languages. Case sensitivity means that fooBar and FooBar can be valid identifies in the same scope but refer to different bindings. I see many ways where that can produce an errors and very few (possibly none) where it can help create well-structured code. If the names shadow, clash, or override then the error cases become much easier to see and diagnose. Honestly one of my favorite tiny things about programming in Lisp is the identifier rules. The caps insensitivity, plus '-' being available because there's no infix operators, means that multi-word identifiers are easier to type (no shift key) and IMHO more aesthetically pleasing than underscores or snake case.

Pxtl 8y ago
Yeah, I could see a language taking the position that referencing fooBar as FooBar is an error, and that level of case-sensitivity makes sense to me (my name is Martin not martin) but allowing both Martin and martin to exist as distinct identifiers is crazy. On the subject of spaces, I do wonder why no language has used enough punctuation to make spaces allowed in identifiers. I mean, most Algol-derived languages could get away with it if they put punctuation between type keywords and variables: private, my class: my instance = my factory function(my parameter one, my parameter two);
- jfk13 8y ago
  > make spaces allowed in identifiers IIRC from my days at Cambridge, Algol68 allowed that. (Our local variant was Algol68C.)
- ken 8y ago
  Lisp allows spaces in identifiers, or any other character. You just have to escape them: (defun |my + function| (x y) (+ x y)) (|my + function| 2 2) (Or maybe write a reader macro to deal with them in some other way.)
  - Pxtl 8y ago
    Hah, that's even uglier than the SQL "just put square brackets around it" approach. We're looking for something nicer than underscores and hyphens.
    - andreareina 8y ago
      Being that whitespace is the primary way most languages separate tokens, yeah putting whitespace inside tokens is going to be ugly.
- yoz-y 8y ago
  Robot testing framework language does allow spaces in identifiers and it is a terrible idea.
ken 8y ago
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.htm#case_sensitivity_mode http://clhs.lisp.se/Body/26_glo_c.htm#case_sensitivity_mode I can see why this is available to the reader (it has to handles arbitrary characters), but I have no idea why anyone would ever want :INVERT.
- 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?

by lmkg 8y ago

Pxtl 8y ago

Yeah, I could see a language taking the position that referencing fooBar as FooBar is an error, and that level of case-sensitivity makes sense to me (my name is Martin not martin) but allowing both Martin and martin to exist as distinct identifiers is crazy. On the subject of spaces, I do wonder why no language has used enough punctuation to make spaces allowed in identifiers. I mean, most Algol-derived languages could get away with it if they put punctuation between type keywords and variables: private, my class: my instance = my factory function(my parameter one, my parameter two);

jfk13 8y ago
> make spaces allowed in identifiers IIRC from my days at Cambridge, Algol68 allowed that. (Our local variant was Algol68C.)
ken 8y ago
Lisp allows spaces in identifiers, or any other character. You just have to escape them: (defun |my + function| (x y) (+ x y)) (|my + function| 2 2) (Or maybe write a reader macro to deal with them in some other way.)
- Pxtl 8y ago
  Hah, that's even uglier than the SQL "just put square brackets around it" approach. We're looking for something nicer than underscores and hyphens.
  - andreareina 8y ago
    Being that whitespace is the primary way most languages separate tokens, yeah putting whitespace inside tokens is going to be ugly.
yoz-y 8y ago
Robot testing framework language does allow spaces in identifiers and it is a terrible idea.

ken 8y ago

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.htm#case_sensitivity_mode http://clhs.lisp.se/Body/26_glo_c.htm#case_sensitivity_mode I can see why this is available to the reader (it has to handles arbitrary characters), but I have no idea why anyone would ever want :INVERT.

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?