World: r3wp

if the values are EQUAL

uses no more characters

Case is pretty important, though, so it warrants en explicit mention 
in the docstring.

The other constraints are not even documented on the docs page, at 
the moment.

So if you know any such constraints off the top of your head, please 
add them to the page.

Two suggestions:

>> length? "TRUE for values that are equal and of the same case and 
datatype." 
== 65

>> length? "Returns TRUE for EQUAL? values that are of the same case 
and datatype."
== 70

but i guess you'll want a mention then that case is not applicable 
to all types ...

>> strict-equal? 1-Jan-2010 1-JANUARY-2010
== true

since date has no case, it doesn't matter ...

>> 1-JANUARY-2010
== 1-Jan-2010
>> 1-JAN-2010
== 1-Jan-2010

Yeah, I guess it's a question of what would be considered more irritating: 
STRICT-EQUAL?s docstring pretending that it only differs from EQUAL? 
in that it also considers the datatype. Or mentioning case-sensitivity 
explicitly.

Robert, if you want object! to behave like map!, use SELECT. SELECT 
object! 'field returns none if the field isn't there.

Thx. Yep, that's a good way.

If you're talking about changing object behavior, that would require 
rewriting a lot of mezzanine code. There are many cases where a field 
not being in an object is an error, and it triggering an error is 
relied on in a lot of mezzanine code. If it stops triggering an error 
then we would have to change a lot of code from o/field to EITHER 
in o 'field [o/field] [cause-error ...].

interesting ... 'select now works on objects ... whereas I would 
have normally used 'in

Since the /case refinement is used elsewhere .. why not have

equal?/case

instead of strict-equal?

You can't have an op! call a function with a refinement. STRICT-EQUAL? 
is only there to be the prefix form of ==.

While we are at case sensitivity: any ideas how to proceed regarding 
a case-sensitive MAP!?

Brian, I think you mentioned a few days ago, that this issue needs 
dicussion.

Maybe adding a strict-map! datatype that would raise an error for 
path accesses could be a solution?

And if we are comfortable with the idea that m/a and m/A will typically 
return different values, then we could drop the path access restriction.

I believe the result of the discussion (so far) was to use binary! 
encoded keys for case-sensitive maps.

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.