Following this thread I recall long-ago disputes in IBM R&D and university IT departments about supporting language features such as non-ASCII writing systems, database access (especially relational), *enum*, *class*, *struct* and *const*, right back to the egregiously misnamed "real" numbers.
For my sins, I write a lot of Swift code. Swift boasts a me-too *dictionary* à-la Python, but I've never found a use for it. Except for one single coding task: writing calls to legacy packages. Many of these appeared in the early '90s when *dictionary* was a cool new must-have datatype. People with experience of Apple SDKs will know what a pain-in-the-neck calls are which return *NSDictionary* values or require arguments having that datatype. Mercifully, few do. I suspect my experience is typical of Swift coders. I also suspect most of them don't write code to solve problems as J-ers do, but only to read data from one package and write it unaltered to another. Now I'm aware this is an ignorant attitude. Please somebody show me how wrong I am. With examples. When I first met J back in the '90s, and had to typeset it for VECTOR, it struck me as hostile to the very notion of importing me-too features from other languages. Except as Foreigns or addons. A habit which starved newcomers of familiar landmarks. But one thing J IDE did do well was eat its own dogfood. You can admire the dogfood in locales _z_ and _j_ and I'd recommend beginners to study everything they find there. So… got a coding problem? J IDE solved it before you were born. One clear use for *dictionary* in J IDE would be to reimagine *Public_j_*, *SystemFolders_j_*, *UserFolders_j_* plus much of *0!:* and *1!:* . Please somebody tell me of all the wonderful vistas it would open up for the jobbing J coder. On Tue, 1 Feb 2022 at 09:19, Jan-Pieter Jacobs <janpieter.jac...@gmail.com> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
