REBOL3 tracker
  0.9.12 beta
Ticket #0001437 User: anonymous

Project:



rss
TypeWish Statusdismissed Date20-Jan-2010 08:16
Versionalpha 96 CategoryDatatype Submitted byPeterWood
PlatformAll Severitymajor Prioritynormal

Summary Case sensitive key option for Map!
Description The DocBase entry for the Map! database states that Map! keys are case insensitive. It also includes the comment "should there be a mode to allow that". Allowing a case sensitive option will increase the usefulness of Map!. It would allow building of case-sensitive word list for indexing and spell checking. It would also allow Map! to be used in building tables from the source code of case sensitive languages such as Java and JavaScript and of course, Unix file names.

ANSWER: use binary! keys. They are case sensitive and the examples above would be sourced as binary anyway (as the input from files or directories).
Example code
Current R3 behaviour
>> make map! ["Peter" #[true] "peter" #[true]]
== make map! [
    "Peter" true
]

Desired R3 behaviour

>> make/sensitive map! ["Peter" #[true] "peter" #[true]]
== make map! [
    "Peter" true
    "peter" true
]

Assigned ton/a Fixed in- Last Update4-Feb-2010 18:52


Comments
(0001908)
pekr
20-Jan-2010 12:29

I am not sure there will be strong desire to overload 'make with /sensitive refinement. This one would be used only for map! dtype. Some more general aproach is needed. E.g. objects are going to have some init spec block implemented, and I suggest the same aproach to be taken for another datatypes, if there is some need ....
(0001909)
abolka
20-Jan-2010 15:48

See also #1315.
(0001910)
PeterWood
20-Jan-2010 23:45

I'm not at all bothered by the mechanism by which a case sensitive Map! is created - the /sensitive refinement was just a quick way to write an example.
(0001911)
PeterWood
20-Jan-2010 23:52

Without this extension, I don't believe it is correct to state that Map! is a replacement for Hash!

Strings stored in a Hash! are case sensitive:

>> h: make hash! ["peter" "Peter"]
== make hash! ["peter" "Peter"]
>> find h "peter"
== make hash! ["peter" "Peter"]
>> find h "Peter"
(0001914)
BrianH
24-Jan-2010 04:13

The map! type is only a replacement for hash!, not compatible with it. They have different semantic models. Due to the nature of the map! data model it would be impossible to use case-insensitive addressing with case-sensitive map!, and vice versa. This means that FIND or SELECT /case doesn't work on the current case-insensitive map!, nor could it.

This ticket is a restatement of #1315 as a option. In theory it could be done with a flag similar to the not flag of bitsets. But since words can already be used in map! specs there isn't an obvious syntax method for specifying the flag the way there is with bitset! (suggestions are welcome).

A /sensitive option for MAKE will not happen. MAKE options go in the spec block. MAKE is a very low-level action that won't ever get a type-specific refinement. We have to figure out another way.
(0001959)
Carl
4-Feb-2010 18:50

It's a bit of a mind bender, isn't it?

Although it would be quite possible to allow a MAKE/options refinement to specify variations for any datatype, it becomes very problematic because we like *strong reflection* for MOLD and LOAD. This can only happen for "in-band" specifications... those that are expressed directly in the block argument passed to MAKE map!. Any /options would be lost (unless perhaps a MOLD/all format were used.)

But, there is a solution for the cases mentioned above. Use binary! keys. This is less of a problem than it seems... because the input streams (a source file or file directory) are either ASCII or UTF-8, so in their raw form they're already binary! and upper and lower case will be distinguished in the key.

Date User Field Action Change
4-Feb-2010 18:52 carl Description Modified -
4-Feb-2010 18:52 carl Status Modified problem => dismissed
4-Feb-2010 18:50 carl Comment : 0001959 Added -
30-Jan-2010 23:30 BrianH Comment : 0001914 Modified -
30-Jan-2010 02:53 BrianH Comment : 0001914 Modified -
30-Jan-2010 02:51 BrianH Code Modified -
30-Jan-2010 02:51 BrianH Status Modified submitted => problem
30-Jan-2010 02:49 BrianH Comment : 0001914 Modified -
29-Jan-2010 23:02 BrianH Comment : 0001914 Modified -
24-Jan-2010 05:36 BrianH Comment : 0001914 Modified -
24-Jan-2010 04:13 BrianH Comment : 0001914 Added -
20-Jan-2010 23:52 PeterWood Comment : 0001911 Added -
20-Jan-2010 23:45 PeterWood Comment : 0001910 Added -
20-Jan-2010 15:48 abolka Comment : 0001909 Added -
20-Jan-2010 12:29 pekr Comment : 0001908 Added -
20-Jan-2010 08:16 PeterWood Ticket Added -