That is one of the issues. the 2 solutions when it matters is either ragged array support or boxing the data item.
The other big issue is that key value pairs are just the simplest subset of a table: potentially muti column key, with 1 or more value columns. Looking to k for what they do is worthwhile, but a different proposal: inverted table layout. Key is in first column. If a multi-column key, then key is an inverted table within the first "box"/column If a "field" is not fill resistant (the issue you brought up) then it is boxed or stored as ragged array implementation. An internal table/dictionary structure can be a specialization of regular J columns, where 1. keys are unique enforced, and 2. there may be optimizations for searching on key. One interface option is to describe the table in a similar way to $. giving columns names, and whether or not they are variant or fill resistant(need to be boxed) types. From what I remember, k tables do not require (enforced unique) keys, but can still imply/provide optimized retrieval. Even if most table/dictionary applications can be implemented as uniform data, its important to support boxed data fields. If only to support compound value items. But also precise keys if an application needs those. On Wednesday, April 14, 2021, 11:36:30 a.m. EDT, Henry Rich <[email protected]> wrote: Should keys must have a canonical form so that 0, 00, 0., all represent the same key? What about 0x? Henry Rich On 4/14/2021 11:33 AM, Raul Miller wrote: > That route would work. > > Though I would add "inspect [the dictionary]" as an operation here. > This could initially be a sampling, like J's command line display for > arrays. But some kind of way of inspecting the aggregate is important. > > That said, having keys of "any type" seems like overkill. It's great > for small implementations, but when I think about large deeply nested > data structures, (For example, 30 megabytes most of which is nested > six levels deep across thousands of boxes), I wince. (I think keys > have an implicit "relatively small and simple" requirement.) But don't > let me stop you if you want to go there. > > But, sure -- having an example application to characterize the use of > the system would be nice. And, there, I suppose a locale-as-a-hash > would be a good starting point (since a person could build a sample > application on a prototype and the application could then be used to > further characterize a "next implementation"). > > With that in mind, here's a prototype: > > newdict0_z_=:{{ > (;:'hdict0 z')copath dref=. cocreate'' > dref > }} > > add_hdict0_=:{{ > (enckey x)=: y > EMPTY > }} > > enckey_hdict0_=:{{ > '_hdict0_',~a.{~70+(+ 8*20<])2#._5]\,(8#2)#:0-.~a.i.3!:1 y > }} > > get_hdict0_=:{{ > ". ::_: enckey y > }} > > ------------ > > Example use: > > D=: newdict0'' > 42 add__D i.3 3 > 'fred' add__D p:i.9 > get__D 42 > 0 1 2 > 3 4 5 > 6 7 8 > get__D 'fred' > 2 3 5 7 11 13 17 19 23 > > Note, however, that I have not supported "inspect the dictionary". > That's doable, of course, though obviously it requires additional > implementation -- probably doubling the size of 'add' and 'get' and > throwing in an additional verb approximately the size of this initial > implementation. > > I hope this helps, > > -- > Raul > > > > > On Wed, Apr 14, 2021 at 10:56 AM Henry Rich <[email protected]> wrote: >> Let's get a spec for what we need before we implement. >> >> 1. What datatypes are needed? >> * Dictionary >> >> 2. What operations are needed? >> * Add key/value pairs >> * return value for a given key >> >> 3. What are the types of key and value? >> * they can have any type >> * perhaps the keys have to have all the same type, values likewise >> >> Please fill this out. This is as far as I got, and for that I think the >> Dictionary type could just be a numbered locale with a few methods. >> >> Henry Rich >> >> >> >> On 4/14/2021 10:47 AM, Raul Miller wrote: >>> Conceptually, here, you're probably thinking about using hashes of >>> character strings as array indices. >>> >>> A character string, in J, is either a boxed rank 1 list of characters >>> or a rank 1 member of a higher dimensional character array which has >>> been padded on the right hand side with spaces. >>> >>> Since all of the current array index primitives throw an error when we >>> try to use characters to index them, I think that we would not need >>> any new primitives -- we would "only" need to characterize the >>> normalization process used to convert arbitrary character arrays or >>> boxed character arrays to array indices. >>> >>> That said, these hashed arrays would also be sparse. And, it would be >>> desirable to support boxed items and boxed hashes. And that gets into >>> some issues which are ... rather involved, if we think about the >>> existing sparse array implementation. >>> >>> So ... when estimating this task it might be best to think of it as >>> "re-implementing sparse arrays from the ground up"? >>> >>> Thanks, >>> >> >> -- >> This email has been checked for viruses by AVG. >> https://www.avg.com >> >> ---------------------------------------------------------------------- >> 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
