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

Reply via email to