World: r3wp

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.

This is why portable use of those filesystems tends to not use filenames 
that only differ by case.

Yes, but that is totally besides the point

There is perfectly portable code that can work as expected both with 
case-sensitive and case-insensitive filesystems

But to write such code in R3, we _can not_ use filename as map! keys 
as-is

There is a way around that on windows I think.

Just collected the short name for all the files using dir/x and then 
you can create a map for all of them.

non-posix ntfs is case insensitive anyway, so it's not really an 
issue on most windows systems