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
