A large share of real data is organized in tree-like structures where lists (integer indexes) are mixed with dictionaries (arbitrary type indexes). An obvious example would be http centric APIs where json use is pervasive -- accessing an element at arbitrary depth is a trivial task in other languages. Below is an example of getting a title of the first post in python, what would be the current j equivalent?
Regards, Danil #!/usr/bin/python3 import json, urllib.request url = "https://jsonplaceholder.typicode.com/posts"; data = json.loads( urllib.request.urlopen(url).read().decode()) print (data[0]["title"]) вт, 1 февр. 2022 г. в 15:47, Ian Clark <earthspo...@gmail.com>: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
