One of the problems you're going to run into right away with making dictionaries a core part of J is the concept of rank, which doesn't really exist in K (everything is a rank 1 list, hooked together by dictionaries).
At the end of the day, what I think most people want from maps/dictionaries is a sort of syntax sugar for relatively flat boxes. When you slurp in some json object in current-year J, it is a box, possibly with a sort of suggestive index of key names for the json values. Same with jd-like tables (with a few column names you can more or less select by). It would be much nicer and more "current year" if you could slurp in some json and then read the fields off like an associated list in R. You could write verbs like this; making inverted tables with headers. https://code.jsoftware.com/wiki/Essays/Inverted_Table FWIIW the reason Pandas looks the way it does is both inspiration from R's data.tables/frames (which are associated list rank 1 vectors), but also from J and K, which Wes is a big fan of. Anyway the K way is pretty cool, but just creating an idiom of J for "convenient selectors" for the "slurping in a json" and "selecting columns of a table" use cases probably makes everyone happy. No need to specify anything beyond that. -SL On Tue, Feb 1, 2022 at 12:50 PM Danil Osipchuk <danil.osipc...@gmail.com> wrote: > I would second looking at how k approaches dictionaries regarding > operations available and their domain. Uniformity between lists, > dictionaries and function calls is really elegant there too (although > likely out of reach - but maybe still having some parts of syntactic sugar > is possible - like having some forms [ ] of notation, yes identity > functions have to be renamed may be to x. and y. making it a drastic > change, but can we dream?). > > But putting syntax aside, at the very minimum, to me, if it is not a tree > like structure with keys of arbitrary type, such a thing is not of much > added value. After all j is already extremely well equipped to handle > rectangular data and people can manage it perfectly well. It is precisely > in tree like data structure things get awkward quickly > > Regards, > Danil > > вт, 1 февр. 2022 г., 10:12 Raul Miller <rauldmil...@gmail.com>: > > > Another model to think about here is K's implementation, where the symbol > > table is a tree, and thus supports contexts which do not have equal > length > > columns. > > > > -- > > Raul > > > > On Mon, Jan 31, 2022 at 9:54 PM Ric Sherlock <tikk...@gmail.com> wrote: > > > > > > otoh, we already have a binding to R where you can deal > > > > with dataframes easily – do we want to “compete” here, too? > > > > > > > > In terms of whether to just adopt/use one of > > R's/Pandas'/Polars'/Julia's > > > dataframes rather than reinventing the wheel - I think for me that if > it > > > were possible to use J primitives to interact with the dataframe > > directly, > > > that would be really compelling. If that were possible with a binding > to > > an > > > external implementation, then I'm all for it. If not then I think it is > > > still worth discussing J native dataframes. > > > ---------------------------------------------------------------------- > > > 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
