On Thu, 9 Jun 2022, Raul Miller wrote:
when [local variables] can be accessed, they can be updated.
Updating locals is a local transformation, not global, in which respect they
can be seen as syntax sugar.
Perhaps this distinction is best illustrated by considering memory mapped files
-- here, J bends its rules, mapping J values onto OS managed storage.
JE has a policy of not allowing strong pointers, only weak pointers (mutexes
are a notable recent exception). If you manage to get your hands on a memory
mapped file--that's a strong pointer (sort of). Various operations like { and
} magically change their behaviour when operating on pointers. But what you
are observing here is a change in the data pointed to by the variable, not in
the variable itself.
(In languages with closures, local variables really are mutable.)
When things are not working right, how does the developer inspect values stored
in thread-local names in the suspended thread (or task-local names in the
suspended task)?
T.n switches to thread number n while debugging. Presumably that also gets you
access to n's task-locals.
That said, I am getting the feeling that we ought to adopt the "use case"
discipline here. Presumably you have in mind some useful model of how this would be used
-- coroutines or whatever. And, I think, those sorts of examples should be made explicit,
so that we can better understand them.
Sure. I don't have a particular use-case in mind, for myself, at the moment.
But consider jd: it uses global variables to pass around state. And I know
Eric said he wants to parallelise it (at least for queries). Changing those
variables to be thread-local would be a minimally invasive way of enabling such
a change.
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
