map keys are case-insensitive only

[Oldes]

In Rebol:

>> make map! ["a" 1 "A" 2]
== make map! [
    "a" 2
]

while in Red:

>> make map! ["a" 1 "A" 2]
== #(
    "a" 1
    "A" 2
)

Isn't Red's version more useful?

[hostilefork]

Ren-C started doing case-sensitive storage and allowing case-insensitive lookup around here:

metaeducation/ren-c@543faca

There are some semantic questions about what it means to do case-insensitive operations (lookup, removal, unions, whatever) in a map with multiple matches with different cases. It's not easy to serve two masters. I'd prefer things like that give errors than be random.

(So calling it "Ren.resolved" is a bit of jumping the gun, but I would say that it can be done certainly as well as whatever Red does, if that's what the issue topic is.)

[Oldes]

Ren-C is than not compatible with Red, where setting/getting is still case-insensitive by default.

> m: make map! ["a" 1 "A" 2]
== #(
    "a" 1
    "A" 2
)
>> m/("A"): 3 m
== #(
    "a" 3
    "A" 2
)

For setting using case-sensitivity, there is a put action in Red:

>> put/case m "A" 4 m
== #(
    "a" 3
    "A" 4
) 

There is a wish for the put: #2392

[hostilefork]

At least on the surface of it, I prefer Ren-C's solution (as opposed to to using up a term like PUT for something like this).

My angle is that it's better to have the user of a MAP! make a decision: They must decide whether they expect to be putting distinct forms of the same item into the map, yet expecting them to be fetched insensitively. If they have that expectation, they should canonize their data before they put it in. Then they only worry at insertion time.

---

For whatever it is worth: I feel that the entire model needs a thinking over. Carl had an initial idea of a very "brick-like" system that used BLOCK! concretely--even so far as to use a HASH! to index a block for making it faster (while still looking very much like a BLOCK!).

Because things like MAP! have these very "abstract" properties for serialization and usage, I've been wondering if there should be a very conscious shift away from teaching the casual use of such things. Instead, consider they are tools that are reached for only by large-scale applications that absolutely require them. And if in that process, they are allowed to become very "non-Rebol-like", that's not so bad.

Some brainstorming on this matter of pushing "back toward concreteness":

https://forum.rebol.info/t/block-and-object-parity-in-pathing-picking/1086

...but it is "only a feeling" at this point. My concern is that Rebol is less pragmatically usable than JSON as an exchange medium--even when both sides are speaking Rebol--which makes me feel like a step back may be needed.