World: r3wp

At least in my typical usage scenarios, a get from a map far more 
often than I put into a map.

Yup, and that is the usage pattern that maps are optimized for.

Using binary! for keys would then have two effects:
- Lots of code gets more unreadable
- A map! is unsuitable for anything performance-related

`a/(to-binary k)` vs `a/:k`, in the simplest case

performance will be less of an issue once we have support for a fast 
codec (utf-32/ucs-4), leaving mostly the extra function call(s)

Not necessarily - most map usage with non-word keys tends to not 
use literal key values. Case-sensitivity wouldn't affect word keys 
(your m/a vs. m/A) so it would mostly affect data that can be kept 
binary end-to-end, if necessary. Still, I wouldn't mind case-sensitivity 
as an option, as long as there was a syntactic way to specify that 
option. No, MAKE can't have a refinement.

Once someone comes up with a decent syntax for specifying case-sensitivity, 
we can do case-sensitive maps.

words have case as well, so word keys are affected as well

is an additional datatype too heavy a way for this?

No, they wouldn't be. Words are case-preserving, not ever case-sensitive.

>> strict-equal? 'a 'A
== false

>> select/case [a 2 A 3] 'A
== 3

>> select/case [a 2 A 3] 'a 
== 2

Weird, I wonder when that started to behave that way.

An additional datatype is a possibility - suggest it in bug#1437.

I wouldn't expect it to succeed though - case-sensitive maps have 
been suggested twice, and dismissed twice.

My ticked re case-sensitivity is not yet dismissed, but reviewed 
(#1315)

And bug#1437 was dismissed rightly due to the desire for a MAKE refinement.

I will post the suggestion to bug#1315 instead, as I cannot re-open 
dismissed bugs, and I think the suggestion will get lost if it's 
buried in a dismissed bug.

bug#1437 was more likely, but try making the suggestion of an additional 
datatype in the other. Watch out though, since there are many tickets 
that are still current since we (mostly Carl) haven't gotten around 
to going over them yet.

Can you change the status of #1437 to something other than dismissed?

Yes, but it can't work so I shouldn't. A new datatype could work, 
but there is no way a MAKE refinement will be added, and there is 
no way to add the option to the spec syntax.

Ok, I'll just submit a new "wish" bug then

Good luck. Adding a new regular datatype is a big deal - there are 
only a fixed number that we can have overall. User-defined datatypes 
are supposed to enable us to make more, but there can onle be a limited 
number of true datatypes.

So limited that typeset! values are immediate types, fitting inside 
a value slot.

I'm in favor of a strict-map! type, if my support counts.

:)

If the number of types is an issue, I personally would rather prefer 
it the other way round. Having a case-sensitive map per default and 
having the user use LOWERCASE on keys if case-insensitivity is desired.

Case-insensitivity will be what is needed most of the time. Particularly 
for word types, but for strings too.

Maps are used most often as a variant of the object type with slightly 
different behavior (mentioned by Robert above).

Maybe it's just because I'm spoiled by case-sensitive languages and 
operating systems, but I can't see how case-insensitive strings are 
ever useful.

I would mostly use a map! as a hashtable

BrianH can vectors be made extendable, shrinkable?

would be nice to append beyond the end of a vector but I guess that 
would defeat it, correct?

Sorry, REBOL is case-insensitive by default in almost all cases. 
Something to get used to. At least R3 is case-preserving for words.

Paul, as vectors are supposed to be contiguous regions of memory, 
it would be possible, but appending would either be _very_ slow in 
general or of unpredictable preformance at the cose of increased 
memory usage

Brian, I don't have any issues with REBOL being case insensitive

But my filesystem simply is not, for example

Yeah that is what I thought.  I didn't think it would be possible 
without rebuilding the vector to some extent.

Also, it would depend on whether the dimensions of a vector are considered 
part of their definition. And that would break multidimensional vectors, 
which are still planned.

ok thanks.

And if I want to use filenames as keys, I already need to do `to-binary 
to-string`

You can use filenames as keys as-is, if your code is portable.

No, I can't

Portability has nothing to do with it :)

Ah, your code must not be portable - if it was then you couldn't 
be using filenames that differed only by case.

Let's say I write a script that displays the number of files in all 
current subdirectories

Let's say I want to store those numbers in a map! associating the 
subdirectory name with the count of files

Perfectly portable code, but fails on case-sensitive filesystems

Yeah can't use different case names in map.

Right. Case-sensitive filesystems aren't portable to the main client 
OS'es, or even all server OS'es.