Interesting discussion. My little addon (https://github.com/jpjacobs/types_dict <http://www.github.com/jpjacobs/types_dict>) works pretty well in my test, with any rectangular data (including boxes) as either keys or values. My only gripe with it was that due to subtle details of inverse in combination with locales, the lookup of keys by values cannot be immediately implemented with the inverse of values by keys, but this is minor. When writing the addon, I haven't thought about any inter-dictionary operation, nor any primitives to work with the dictionaries, but I do see how they could be useful, e.g. joining dictionaries (,) , making set difference (-.), # for the number of elements, etc.
I do not understand what you intend with shape and dimensions of a dictionary. As far as I understood, dictionaries are just a bag of key:value pairs, which, in good implementations, can be any valid data type. If not, it starts looking like a dataframe/inverted table/... which could be implemented using a dictionary of columns, but I think a distinction should be made. I personally like a lot the way Lua (http://lua.org) handles dictionaries (called tables): - They allow any type for key and value (heterogeneous) - successive positive keys are used for using a table as array (downside: indices are 1-based) - They can be nested - They also have what they call meta-methods, defining what e.g. table1 + table2 or any operation should mean, but also offering the possibility to override indexing, assignment, calling a table as function ... by Lua functions (or C functions). This allows implementing OOP or whatever you want. The Lua shared library is also tiny, if I recall correctly around 350kB for the interpreter and all standard libraries. The Lua language itself and its C API is very simple, very stable and very well documented. So I wondered it would not make sense binding Lua to J, and took an initial attempt at it here: https://github.com/jpjacobs/api_lua but didn't get very far beyond opening, evaluating Lua commands and closing a Lua State due to lack of C experience. I guess the difficult part in such enterprise would be the marshalling of data or pointers thereto between J and Lua... Maybe someone interested could take my dabbling as a starting point for something more serious :). On Tue, 1 Feb 2022 at 08:55, Elijah Stone <elro...@elronnd.net> wrote: > > I disagreed with 'symbols' in 1 > > Roger Hui writes: > > > Premature optimization is said to be the root of all evil in programming > > [Knuth 1974, p.671], but premature generalization is worse. Premature > > optimizations can at least be backed off > > If we start with only symbols as dictionary keys, then it is easy to let > other objects be keys later; but it is much harder to do the reverse. > > In particular, I do not like (<<x) { y, and that is not necessary if only > allowable keys are symbols. > > > > b. I envisioned Dic , newitem as the idiom to add an item to Dic. > > newitem would be an item of Dic. > > I still do not understand. A dictionary maps keys to values. I infer > from what you say that newitem is a value. Where is the key? > > > > Duplicate keys are interesting and important. There needs to be a > > way to get the set of values associated with a key. > > Wait--one key can be associated with multiple values? An array is now a > multi-valued function? I strongly object to that. > > > > 2c. The number of keys is surely of interest, as is the number of > > distinct keys. There needs to be some way to query that, and ($ Dic) > > seemed good for the number of keys; perhaps ($@~.) for the distinct keys > > Ah--what semantics were you envisioning for ~.? I imagined that, if > supported, ~.Dic would return a dictionary whose keys are a subset of > Dic's, such that no two of the values are the same as each other. The > difficulty would be deciding, given two keys corresponding to the same > value, which to pick. > > But given your mention of 'distinct keys' (and above the 'set of values > associated with a key') I think we may still be talking about very > different things when we say 'dictionary'. > > > > 2e. This is a real issue. You say 'keys should not be ordered' but I am > > not sure about that. This needs discussion. > > I think of an array as a function. A function's domain is not inherently > ordered. We may impose some ordering on it; what should we impose (if > anything)? > > J defines two orderings: < and /:. Ordinary array's domains are sorted > according to both. Which is the interesting one? I think it is <. < has > interesting properties; /: is simply total for the sake of being total. > And as < is not total, it is not suitable for ordering dictionary keys. > > An alternative is to retain insertion order. I think this is definitely > better than ordering according to /:, but am still sceptical that it is > worthwhile. I still do not think of maps as having order. > > > >> At least: domain (new primitive) index transpose amend apply-at-rank > >> filter indices. From rank follows any rank-0 operation. Maybe: key > >> catenate shape reshape nub index-of tally reduce. > > > > Please: when I was younger, I might have said 'What you say makes no > > sense' to mean you were wrong; but after a long life of making mistakes > > I mean no more than what I say: I don't get what you're saying. It > > might be that I'm dense. > > I definitely did not mean to imply that! Just did not know what you > were referring to. > > I think the following should definitely be supported: > > key { Dic > > |: Dic > > axes |: Dic > > values keys} Dic > > u"n Dic > > Dic # Dic > > I. Dic > > Because u"n Dic works, any primitive of rank 0 may be applied to a > dictionary. I think there should also be a new 'domain' primitive that > gives the domain of an array. > > I think the following should perhaps be supported, but am not sure: > > Dic u/. Dic > > Dic , Dic > > $ Dic > > shape $ Dic > > ~. Dic > > # Dic > > u/ Dic > > Dic1 i. Dic2 > > The last sentence results in a mapping from the keys of Dic1 to keys of > Dic2 (call it R), where for any i, (i{Dic1) -: Dic2 {~ i { R. Problems > with i., /, ~., and /. are all the same: order. > > -E > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
