And another year goes by, and the tumbling continued...
With the virtual binding change has come case-sensitive binding.
>> FOO: 10
>> foo: 20
>> FoO: 30
>> FOO
== 10
>> foo
== 20
>> FoO
== 30
These features wound up connected because WORD! cells only have so many bits in them. So I sacrificed "spelling-variation-bits" to give "virtual-binding-bits".
We should be cautious in using case-sensitivity as a "feature" until we understand it better, and if it's what we actually want. If you don't start leveraging this as a purposeful feature, we could roll it back. There are other options--like increasing cell size--which could be pursued.
But as I've explained, Case-Preservation and Case-Insensitivity are fundamentally at odds.
With binding being case-sensitive, this leads me back to my original feeling that case-insensitivity should likely be the is operator, and that = be the more "exactly equal" notion of case-sensitive equality.
>> 'Foo = 'foo
== #[false]
>> 'Foo = 'Foo
== #[true]
>> 'Foo is 'foo
== #[true]
>> 'Foo is 'Foo
== #[true]
My instinct is that the "I don't like having to be overly precise" nature of people who would want to gloss case, would go along with "I don't like math or code that looks like equations"...and that such a person would be happy typing IS and getting case-insensitivity with that.
Predicates Semantics: Harder Than Expected
Using predicates with things like FIND is a bit tricker than I thought because they work on arrays of items.
>> find [a b c d] [b c]
== [b c d]
If you're going to pass in a predicate to override the default, if that predicate can only compare two values against each other...that's a bit constraining. It means the operator doesn't ever see both the [b c] items in the comparison at once, it's only comparing the arrays member-wise.
Figuring out where to put the predicate is a bit confusing also:
>> find .is [a B c d] [b c]
== [B c d]
>> find [a B c d] .is [b c]
== [B c d]
>> find/predicate [a B c d] [b c] :is
== [b c d]
And /PREDICATE is a really long name for the refinement, which makes /WITH seem appealing to take for this purpose (though it's also a possibility for a binding operator, if IN is considered too good as a variable name)
>> find/with [a B c d] [b c] :is
== [B c d]
I liked the idea of having a unified name for predicates, but SORT historically used /COMPARE...
Anyway, I wanted to point out this still hasn't been resolved, and that the binding change would seem to point more toward the idea of case-sensitivity for the symbolic =.