Yes, we are disagreeing only on the difference between unlikely and
asteroid-impact-unlikely.
L., L:, and S: present different problems. L: is straightforward, but
it reconstructs the whole boxing hierarchy even when only the leaves are
modified. L. searches every box, as mentioned earlier. S: does not go
through the common result-assembly code because the number of results is
not known, and ends up recopying the result into
successively-doubling-size buffers. I think the code is right for the
use cases I see here in the Forum, but if a customer has a special need
they would be candidates for rework.
Henry Rich
On 12/18/2023 3:10 AM, Raul Miller wrote:
Ok, but it's not just L.
It's also L: and S:
Also, generally speaking, most applications mostly use a subset of
maybe a dozen J primitives (with different kinds of applications using
a different subset - for example, there's not a lot of call for
exponential functions when manipulating textual reports).
Anyways, probably a [low-priority] call for use cases, and there's
probably other work would would also be needed for some of those use
cases (interacting with some kinds of remote json interfaces, maybe).
Definitely not something for the current J beta.
Thanks,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
