On Thu, Feb 3, 2022 at 4:23 AM Igor Zhuravlov <zhuravlov...@ya.ru> 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.
Specific options here include: (1) symbols -- symbols are scalars. (2) boxed character lists -- boxes are scalars. Downside: a temptation to overgeneralize -- arbitrary boxed arrays as indices can be inefficient. (3) sparse arrays -- this is a bit of a hack, but if you allow arbitrary characters as indices, and pad indices to the same length (perhaps 16 characters), dedicating that length of sparse dimensions gives you a composite key. (This can be done now using a.i. on a list of ascii characters.) Downside -- not particularly efficient. Of course, it's also possible to use a lookup table... but that gets back to what we have now that we might want to better support. The urge to efficiency is something we have to be careful with here (requiring more efficiency than is possible can radically slow or completely stop any effort). But it's still important (lack of sufficient efficiency can make the result be useless or worthless). -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
