miller icon indicating copy to clipboard operation
miller copied to clipboard

Inconsistent mapexcept behaviour

Open trantor opened this issue 8 months ago • 1 comments

Hey @johnkerl ! It's been a long time since I was last active. Anyway, I've noticed an inconsistent behaviour in mapexcept

From the docs:

mapexcept (class=collections #args=variadic) Returns a map with keys from remaining arguments, if any, unset. Remaining arguments can be strings or arrays of string. E.g. 'mapexcept({1:2,3:4,5:6}, 1, 5, 7)' is '{3:4}' and 'mapexcept({1:2,3:4,5:6}, [1, 5, 7])' is '{3:4}'.

Except that the two possible inputs cited DO NOT give the same result.

For instance in my case I noticed that writing emit1(mapexcept($*,5,6,7)), emit1(mapexcept($*,"5","6","7")), emit1(mapexcept($*,["5","6","7"])) all return the intended result, instead emit1(mapexcept($*,[5,6,7])) gives me an empty output. I think that type inference might be messing things up compared to what writtten in the documentation. I also think that the documentation for similar functions, if this behaviour is intentional, should be rewritten.

I am not sure whether the correct behaviour is what actually happens or what is in the documentation. Or if the combination with emit1 is throwing things off. Please enlighten me! :)

trantor avatar Apr 10 '25 09:04 trantor

Hi @trantor !

I don't have any mechanism to auto-run things from help strings -- so it's quite possible something changed (including type-inference) since I wrote that help string :|

I got

[mlr] mapexcept({1:2,3:4,5:6}, 1, 5, 7)
{
  "3": 4
}

[mlr] mapexcept({1:2,3:4,5:6}, [1, 5, 7])
mapselect: unacceptable value 1 with type int; needed type string

johnkerl avatar Apr 10 '25 13:04 johnkerl