I am a little uncomfortable with this combination of statements:
"I have been experimenting with a tacit style where the y "argument"
represents the state of some big complicated object or system ..."
and
" gsn y -> ignore y and return S"
After reading it a few times and looking at your examples, I figured
it out. But monadic gsn depends on y, it's not ignoring y in that
sense, it's ignoring y in the sense that it is ignoring that y
*convention* and producing a result which (if it was a y argument)
would not conform to that convention (unless the state concept is
recursive in this context).
So... that's one thing. I think the comment on monadic gsn should be
something like "extract S from state" -- but that still needs an
example, and there's probably a better way of saying that.
But, also, automatically generating stuff like gsn seems doable with
just a little bit of code, but it seems like the details for doing
that usefully should depend on the application. But if the names are
to be meaningful, they should probably be generated "manually". (And,
if they're not meaningful, using raw indexing seems to make more
sense.)
Take care,
--
Raul
On Tue, Sep 14, 2021 at 12:06 PM Michal Wallace
<michal.wall...@gmail.com> wrote:
>
> Let me amend what I was just saying about name:: ...
>
> I have been experimenting with a tacit style where the y "argument"
> represents the state of some big complicated object or system... for
> example, the state of a parser or a virtual machine.
>
> I've found that "accessor" verbs are really handy, and allow you to
> decouple your tacit code from the actual implementation of the object.
>
> An accessor 'gsn' (for "get/set 'n'") is a ambivalent verb that works like
> this:
>
> gsn y -> ignore y and return S
> x gsn y -> ignore y. sets n to x and return S
> S here indicates whatever the "state of the whole system" is...
>
> 'gsn' here is a pronoun (proverb?) -- If you had three state variables
> n0,n1,n2,
> you would make three such verbs, gsn0, gsn1, gsn2.
>
> This is quite flexible. If you want to store the state of your system in an
> object or namespace,
> you can implement gsn like so:
>
> gsn0 =: {{ n0__state }} :: {{ n0__state =: x }}
>
> Then the y argument you pass is just '' or whatever you want, since it's
> ignored.
>
> Or you can choose to implement the state as some physical array structure,
> which gets accessed and modified in place:
>
> gsn1 =: {{ 1 { y }} :: {{ x 1 } y }}
>
> It would be nice if these accessors could be created automatically.
>
> For example, (if we weren't about to be using the syntax for 'self effacing
> names', we might
> use name:: to work as the accessor)... And then:
>
> name:: y could:
> - invoke name__y if y is a reference
> - extract they value for key 'name' from y if y is some kind of dictionary
> - extract n { y if 'name' is defined as a constant number
>
> x name:: y would do the analagous things for setting the value to x.
>
> Many object-oriented languages (python, C#, javascript) give you the
> ability to define such accessors either for specific names, *or* to design
> generic accessors that take the name as a parameter.
>
> For example, in python, you can arrange for y.x = n to do any of the
> following:
>
> 1. explicitly set the x attribute of object y to n (no accessor defined)
> 2. call a specific y.set_x(n) method
> 3. call a generic y.__setattr__(key='x', value=n) method
>
> My proposal is that x name:: y would have similar range of features,
> depending on the presence of certain handler verbs in the implicit locale
> (if y -: '') or on y itself.
>
> Likewise, 0:: 1:: _1:: etc could be recognized as 'index accessors'
> when y is an array.
>
> If you wanted to get really crazy, then ( index ):: could produce an
> explicit accessor function, where index is some noun that could be passed
> as m in m { y.
>
> This final form could perhaps even use the incredibly convenient "subarray
> notation" of x ;. 0 y , (which is an amazing "getter" but AFAICT, has no
> "setter" equivalent )
> https://code.jsoftware.com/wiki/Vocabulary/semidot0#dyadic
>
> Here is some example code (parser combinators) that uses the "y is a
> structure" concept, where the pattern makes it very handy to implement
> backtracking.
> https://github.com/sabren/b4/blob/master/j/parseco.ijs
>
> Here is another example (virtual machine) using the "y is ignored" style,
> where the accessors get and set locale variables.
> https://github.com/sabren/b4/blob/master/j/b4.ijs
>
> This one in particular uses the idea to partition the virtual machine
> instructions into two sections.
> The "microcode" provides accessor functions that get and set registers, and
> then
> the "instruction set" is defined in terms of these operations.
> This way I can decouple the instruction set from the actual implementation
> of the virtual machine's internals.
>
> Right now it just stores registers and memory cells in separate variables,
> but an alternate implementation might instead store everything in one big
> memory-mapped file, so the machine state could persist on disk or be shared
> between different processes, and this would only require swapping out the
> "microcode" layer.
>
> Anyway, I know the syntax part of this is still a half-baked proposal, but
> the actual idea is very usable now, and pretty fun to use.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
