I should also point out that a bounded 0 T. '' mechanism -- one which creates threads up to a desired limit -- would need a reliable locking mechanism which would stall all other uses of T. for counting or creating threads until the desired number of threads has been created.
Without that, we must cope with creating a number of threads based on an inaccurate thread count. FYI, -- Raul On Fri, Apr 29, 2022 at 2:01 PM Raul Miller <[email protected]> wrote: > > 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
