Hi Pascal, I responded inline below: A workaround is to optimize SET, ADD, UPDATE, DEL for bulk operations > (multiple items processed at once (] F..) super useful), and after bulk > operations, "redefine" (just repeat execution of same definition) GET such > that any m&i. updates. Also update FILTER functions (GET multiple if they > gain from static binding optimization. >
This is, if I get it correctly, exactly what my dict implementation ( https://github.com/jpjacobs/types_dict) does: it allows setting/updating/removing multiple keys and the lookup verbs used are updated only if there is a change in keys > > An approach that just presumes key uniqueness instead of enforcing it, is > for GET to be based on i: instead of i. and then any ADD with a duplicate > key effectively will return the last updated/added values. > This would gather a lot of garbage and would loose the advantage of in-place updating. > > Back to generic datastructure, everything a class can do is possible > within a datastructure. All administrative "properties" (names) and their > associated values including functions can be encoded in a dictionary, > including a string representation dsl for representing "name values" with > ease as to function/data. What specializes a datastructure over a "mere" > class is the concept of existential data held by the datastructure that a J > user would want complete access to that data. In a class based > implementation, a universal name data =: holds the core data that the J > programmer would want access to. Usually, it is compound greater than > atomic data that can be represented as inverted tables of "linked data". > And part of the data specifying dsl's purpose is to include descriptions > that permit any possible optimizations that include what k/q's attributes > do (sorted, unique), but with extensible dsl, any other > implications/constraints on the data can use/select a specific > implementation of universally named "accessors"/functions > So a datastructure contains 2 boxes: 1st holds the name of the > datastructure class (for lookup value of any metadata of that classname), > and all administrative properties, and specialized functions for > GET/ADD/DELETE and other functions expected to have meaning relative to its > "existential" data, and the 2nd box holds the (likely compound and so extra > boxed) "data" > > An advantage of a compound datastructure over a class is the user gets to > decide whether to overwrite the "permanent" data while still having access > to SET/DEL/ADD functionality of their own copy they may want for their > application/data needs. It is also possible for generic GET/ADD/DELETE to > query the datastructure as to how it can best accomplish its integral > functionality, should there not be a specialized version defined in the > datastructure, and GET as an adverb that takes either '', > datastructure_name, or a specific instance of datastructure can optimize > itself as a first step, or one that can be bound to an optimized named > function, or if '' is the adverb parameter to GET, then the generic verb > "inspect y for datastructure properties" before selecting implementation is > returned. > I think these ideas are pretty much what Lua implements with its tables (dictionaries that can contain anything as keys and values, joined by their metatables, i.e. tables that can contain functions to override e.g. indexing operations). These tables do everything: from working as locales (function environments), over separating modules (our addons) to implementing OOP (making liberal use of the __call metamethod, specifying what happens if you calln a table as if you were calling a function, and __index, specifying what happens if you try to get a non-existent key in a table). In my view, the problem with a locale-based dict implementation like mine is currently that you cannot nest dicts without loosing generality. As numbered locales are referred to by boxed numbers, you could make a special case for these in your implementation, but would evidently loose the possibility to store boxed numbers. Even when adding checks to whether a boxed number is a locale, one cannot be sure the user intended to refer to a locale or actually wanted to store a boxed number. One could think of using the locales themselves as dicts, but there you'd have the problem that: - only valid names can be keys - referring to values is only possible with dict__key, which precludes doing so tacitly. For such implementation to work, one could (note, I have no clue about the implementation itself :p): - make a datatype only for referring to locales - implement indexing into that type with {:: following more or less the same idea as indexing with {:: - providing a verb to amend along the same lines - have a conjunction DoneIn that allows something like verb DoneIn mylocale (could be called 'of' as well) - allowing any value as "name" in locales. Like that, implementing a dict that allows storing arbitrary keys and values, nesting dicts and even self-reference, reference loops etc, using locales would become possible. In the end, I guess this would end up at about the same functionality as Lua does for tables… so I don't know what's more effort: implementing everything in J/C, or binding Lua. There's been a time I would have loved to have Lua instead of J's explicit language, but I guess that would end up as a different language :). Jan-Pieter ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
