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, -- Raul On Mon, Dec 18, 2023 at 12:32 AM Henry Rich <henryhr...@gmail.com> wrote: > > The chicken-egg point is valid. > > I'm saying something stronger: applications requiring high boxing levels do > not need L. enough to justify the overhead imposed on ordinary boxed arrays. > > And stronger than that: even if an application is known to use heavy > boxing, the overhead of keeping the level is probably not justified even > within that application. > > Henry Rich > > On Sun, Dec 17, 2023, 4:04 PM Raul Miller <rauldmil...@gmail.com> wrote: > > > That's something of a chicken&egg problem, isn't it? > > > > We avoid inefficiencies in the implementation, therefore those aspects > > of the implementation do not see much use. > > > > That said, there are other issues here (developer time, especially). > > But I'd prefer to think of this as an open issue which might be > > resolved in the (possibly distant) future. (I've stumbled into J > > representations of C++ objects which had been streamed to a file which > > needed about 6 or 7 levels of boxing, for example.) > > > > Thanks, > > > > -- > > Raul > > > > On Sun, Dec 17, 2023 at 2:57 PM Henry Rich <henryhr...@gmail.com> wrote: > > > > > > Based on my scant usage of it, caching would t take more work than it's > > > worth. > > > > > > Henry Rich > > > > > > On Sun, Dec 17, 2023, 12:13 PM Raul Miller <rauldmil...@gmail.com> > > wrote: > > > > > > > On Sun, Dec 17, 2023 at 11:50 AM Henry Rich <henryhr...@gmail.com> > > wrote: > > > > > FYI: L. by itself is usually a mistake. It recurs through all > > boxing to > > > > > the bitter end. Better to use (0 < L.) which allows early exit. > > > > > > > > Hmm... at least on 64 bit architectures, it seems like L. would > > > > frequently be worth caching (might need a "don't know yet value" for > > > > some operations), especially when it's small. > > > > > > > > That said, I don't know enough about header field use patterns to say > > > > where this could best fit. > > > > > > > > -- > > > > Raul > > > > ---------------------------------------------------------------------- > > > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
