fuzzball-muck
ARRAY_INTERSECT does case-insensitive string comparisons
> @muf { "TEST" "TEST2" }list { "TeSt" }list array_intersect
Program compiled successfully.
Result: {"TeSt"}
Is this deliberate? I don't see this behavior documented in man array_intersect
Here's what I've found in a very brief look at the code. This appears to be a symptom of array_tree_find (called when trying to find items from one in array in the other) being called with a "case_sens" argument of 0. It also appears that this argument can only ever be non-zero during ARRAY_SORT.
Unfortunately, my attempt at testing by changing the 0 to 1 in array.c:454 made your code above crash the MUCK (What?). There might be a reason though.
I've heard a perspective that since MUCKs are case-insensitive places by nature, this behavior should be expected. Not sure I agree with that 100%. Once this logic is unwound a bit more, would a $pragma for comparison help?
Also - possibly for another issue, but it seems related: should we introduce a == operator (and a !== internal define) to MUF to force type coercion - so 3 "3" == wouldn't throw an error?
So setting and getting props is consistently case-insensitive and always has been, true. But I wouldn't expect an array operation to be case insensitive just because props are. Saying MUCKs are case insensitive by nature doesn't really fly for me.
At a minimum we should document this. I'm not sure if we care to fix it past that? Instead of a pragma, should we have it be a seperate prim? I dunno. We could have an array_intersect! prim or something like that which forces case compare.
As for == I'm on the fence about that. While I appreciate the convienence of it, to me, the type compares help me debug. But, that just means I don't need to use it :) So I suppose why not?
I like the separate prim idea, and I also like the convention of adding a "!" for an exact match. @dbenoy, thoughts?
I assume there are other prims like this besides array_n_intersection and the define array_intersect. Would be good to get a list together. So many things to document!
Those case-intensive people, they never QUIT. (... I'm bad at jokes.)
Maybe I'm lazy, but I would probably just document this and move on.
I worked around this problem fairly quickly in my code, and I'm guessing it would take a pretty monstrous array before it started becoming performance critical that this operation happen natively inside a primitive.
Although a pragma for "Everything should be as case sensitive as possible unless explicitly requested" would be nice.
As for that == operator idea, I also probably wouldn't use it, and it probably wouldn't be hard to write something like that as a MUF routine and tweak its behavior to your own liking. (Does "3" == #3, for example? Some people may want it so only "#3" == #3.)
IMHO we should keep primitives to a minimum. If it can be efficiently done in MUF then it probably should, and we always have the option to write a standard library for things like that.
Makes sense to me; I'll check which other primitives may be unexpectedly case-insensitive and document them. I may miss a few.
I'll also add a pragma to the wishlist regarding case comparison. I wonder if it's useful to eventually support turning off pragmas - like $pragma case_sensitive_comparisons and $pragma case_sensitive_comparisons off. Wouldn't make sense for our current comment pragmas though (unless $pragma comment_loose became an alias for both $pragma comment_strict off and $pragma comment_recurse off?)
Ugh, comment pragmas. It /seems/ like the logic there could be much simpler than it currently is, but my last attempt to refactor it failed spectacularly. That task's up for grabs :)
@dbenoy, would you mind sending an email to [email protected] so we can invite you to the development muck, and give you a @fuzzball.org email forward?