On Fri, Apr 29, 2022 at 1:35 PM Henry Rich <[email protected]> wrote: > Given that a primitive to allocate a single thread suffices, I see no > reason to support more complexity in the primitive.
This argument conflicts with a significant aspect of the design of J, which I would try to express as: J favors primitive recursive (perhaps described as: well bounded) mechanisms with demonstrated high utility, with full recursive (bound omitting, except in a narrowly focussed sense) mechanisms as a perhaps grudging acceptance of academic and edge-case requirements. [Primitive recursive is roughly analogous to "for loops", full recursive is roughly analogous to while loops.] Or: we could build all arithmetic operations using >: <: and $:, and we could build all arrays from pairs, but in J those arithmetic operations are implemented on a base which focuses on frequently used array and math operations. Or: I have some sympathy for the external pressures which led to this: k=. (expression which depends on external characteristics) 0 T.^:k '' But from a linguistic perspective, I do not like it. (And, from a software development perspective: what are the use cases?) Or: "create one more thread" can crash J much more easily than "ensure that Y threads exist". Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
