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
