On Thu, 3 Feb 2022, Igor Zhuravlov wrote:
Map's key can be non-scalar. Therefore, there will be a need to distinguish between composite key, say (1,2,3) and three scalar keys (1), (2) and (3). Or ban composite keys.
This is indeed a problem. Henry's proposal was to require double-boxing of such composite keys. I do not like it, but do not have an alternative. I think it would be fine to prohibit composite keys, to start, and only permit symbols (and perhaps numbers), for which there seems to be an immediate demand and no such ambiguity. There is always the option to expand and support other types of keys later.
IMHO, map as datatype is too far from J array. So, I doubt the need to make it behave the same way.
My view: j's strength is array manipulation. So if maps can not be unified with arrays, better to leave them out entirely. I already suggested a way to make update-heavy workloads performant given current methodologies (i.).
-E ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
