On Thu, Jun 9, 2022 at 3:20 AM Elijah Stone <elro...@elronnd.net> wrote:
> > local variables accomplish something similar
>
> Local variables are not meaningfully mutable. IOW they are not really
> _state_.
I think I am not following your thought process here.
From my perspective, the issue with local variables is that they
mostly cannot be meaningfully *accessed* from outside their local
context.
However, when they can be accessed, they can be updated.
Perhaps this distinction is best illustrated by considering memory
mapped files -- here, J bends its rules, mapping J values onto OS
managed storage. And, as a consequence, updating the *value* updates
the OS representation which in turn reflects back into J's memory.
And, yes, it's a bit quirky, but it also shows a context where local
variables can be accessed (and mutated) outside that local scope.
For example, with:
require'files jmf dir'
example1=: {{
ref=: jpath '~temp/backingstore.txt'
(3 ic i.9) fwrite ref
JINT map_jmf_ 'im_base_';ref
jm=. im_base_
erase 'im_base_'
example2 jm
(unmap_jmf_ 'im_base_') ] jm
}}
example2=: {{
y=. i.-3 3
EMPTY
}}
I get this result:
example1''
8 7 6
5 4 3
2 1 0
Now... I wouldn't normally use this mechanism in this fashion. But it
does at least provide a rather interesting perspective on the
structure of the system.
> > how to debug issues related to it
>
> What do you mean?
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)?
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.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
