I did not implement a canonical form in that prototype. (The first draft didn't even support independent dictionaries -- the bugfix added that.)
Anyways, in my opinion: if keys are going to have a canonical form which merges types, then it no longer makes sense to support "all types". Thanks, -- Raul On Wed, Apr 14, 2021 at 11:36 AM 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
