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