Ok... for that last sentence: Let's imagine that I am working with something which has both an extensive UI and deals with an extensive variety of libraries to get its work done. Maybe some sort of media composition application.
And, let's also imagine that we have found a variety of practical ways of using threading for various IO and math related tasks. So... what happens when a library which uses threads is loaded when we have multiple running threads? Consider, especially, the case where two different libraries which want threads to exist and be used get loaded in two separate threads. Generally speaking, libraries are all going to be loaded "up front" more or less at the same time. Also, generally speaking, programmers are going to take documentation at "face value" and not think about hidden interdependencies. And, once you have more than a few programmers involved, you're going to have to have some approach to either untangle or avoid interdependencies which could cause system failure. Here, the problem is that between the time you count the threads and the time that you create the missing threads, you are likely to have another library which would also have been counting the threads and creating the missing threads. Conceptually speaking, you only want to count the threads once, and you only want to create the threads once, and that's the primitive operation you would want in most libraries. The more tenuous this primitive becomes, the more likely it is that people will run into unanticipated situations because they thought it was just going to work. Or: we do not want thread counting and creation to be running in multiple threads. So designing the language such that that would be a typical case is just asking for future problems. I hope this makes sense? -- Raul On Fri, Apr 29, 2022 at 4:37 PM Elijah Stone <[email protected]> wrote: > > I completely agree. > > (Except that I do not quite understand your last sentence.) > > On Fri, 29 Apr 2022, Raul Miller 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
