Case conversion aside, = doesn't measure mathematical equality because for lists it reports True if the lists look the same, even if they're distinct lists. We have IDENTICAL TO for a narrower equivalence class.
The underlying problem is that we don't make the distinction between symbols and strings that Scheme makes. Two strings are equal only if they're Unicode-equal, but there's a ci-equal? function ("ci" = "case ignored"). Two symbols are equal if they're case-folded equal, in real Scheme. (In R6RS or later, which isn't Scheme even though they call it that, symbols have to be Unicode-equal too.)
(Besides case-folding, I think we should do looks-the-same folding on Unicodes. There are three or four lambdas in Unicode, one for Greek letters, one for mathematical Greek letters, one for special symbols I think... I forget. I'm not really pushing for this because I know it's opening Pandora's box (is the symbol for AND the same as capital lambda?) but I wish they built something like that into Unicode, so you could say canonical_Unicode_character(char) and get a character that looks like the input, such that all other characters that look like the input have the same canonical character.)
Yes, because as presently defined it's the same as = for everything except lists. But we could define it as whatever narrower-than-= class is appropriate for other data types, such as case-sensitive comparison for strings.
But actually I'm leaning toward a Setting, because then it would automatically affect things like CONTAINS and other blocks that work by making equality comparisons. Conversely, we could fix < and > to do case folding before comparisons when the setting says to. (Talk about misbehaving functions, (A) = (a) is True, and (A) < (a) is True also!)
I would have thought that mathematical equality for lists is if they look the same they are the same. The notion of distinct lists only matters if side effects on lists are permitted. And side effects are not part of the mathematical view of things.
The bigger picture here is how much should Snap! strive to match mathematical conventions. I think we largely agree that when we can we should, e.g. using "=" for equality and not assignment. And this should be fixed:
But sometimes there are trade-offs. As Brian has argued case sensitivity often leads to frustrating obscure bugs and yet avoiding it causes some conflicts with the mathematical notion of equality (e.g. the unicode function behaves differently for inputs that are tagged as "equal").
My vote would not be for a setting since libraries may depend upon a different setting. If is identical to is fixed to be case sensitive and two new primitives were introduced for case sensitive versions of < and > then the appropriate behaviour can be specified locally.
But we would also need case-sensitive versions of index of, remove duplicates from, assoc, and probably a dozen other things I'm forgetting that depend on testing for equality. The setting solution automatically fixes them. In other words I'm arguing that libraries' behavior does depend on the setting, but that the library is happy to work either way. This is an empirical question, and before any serious effort along these lines I'd have to go through all the libraries to see what the reality is for each.
Sigh. Its domain is all values, including but not limited to lists. It is defined as being the same as = except for lists, for which it is true only for pointer equality. That's why.
The reason behind the reason is partly to avoid having to give error messages, partly to allow for the case where only one of the inputs is a list, and partly to allow us to consider giving it a specialized behavior for other kinds of values.
By setting I assume you mean a global setting - the problem is that if I construct a block that depends upon case sensitivity then I should restore the setting when I return. I would discourage the use of the command for setting case sensitivity and use something like this
Though it should restore the setting if there is an error calling blocks. I guess the library catch errors block could be used for this.
