On Tue, 1 Feb 2022, Raul Miller wrote:

I think you are thinking about scalar access -- operations which focus on a single key and the associated value.

And, while that does happen, remember that J also supports operation on the data structure as a whole.

I am thinking about operations on many keys (maybe all, maybe not) or their associated values, potentially in a specific order. That is gather/scatter, and will do well if your accesses are clustered and not so well if they are not. What reason have you to believe that accesses will be clustered?

Operations on _all_ values, or all keys and values (in arbitrary order), will perform well regardless.


what we need here, more than anything, are use cases.

Agree.


Perhaps it is a miscommunication regarding the meaning of 'restrictive'? Unordered keys are more restrictive than ordered ones, because they restrict code that depends on a certain order: it must explicitly specify it.

That's not a restriction on the semantics of the implementation, which is what I think we are supposed to be talking about here.

I don't care to mince words. If by 'restrictive' you mean 'restrictive of the implementation', then fine; then opposite is true: the more you restrict what your implementation can do, the more difficulty it will have implementing your semantics performantly.

I don't care what you call it; forcing an order on keys removes implementation freedom which may have a negative impact on performance.

 -E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to