mne and f seem straight forward to define explicitly (I am using j903
beta-q here):
mne=: {{)a
(".@([,'=:',],'&{::'"_)&":&>i.@#);:'()'-.~5!:5 <'u'
EMPTY
}}
f=:{{
u=. u f.
(".(5!:5<'u')-.a.-.":i.10)&{
}}
However, h is more problematic, because the examples show behavior
which was not described.
For example, if I define h like this:
h=:{{
u=. u f.
v (".(5!:5<'u')-.a.-.":i.10)} ]
}}
Then its result matches your first example, but not your second example:
(A B) h ((B C)f)
1 2&({ ) 0 1} ]
C h(B +/ .*D)
(B +/ .* D) 2} ]
And, since the mechanisms I am using are quite different from the
mechanisms you are using, I am sure that there are examples where the
behavior of my mne and f and your mne and f diverge (though I do not
know if these differences are as important as the issue with h).
Still, ... I could define h as
h=:{{
u=. u f.
if. 1 e.(5!:5<'v') e.'!"#$%*+,-./;<=>?@[\]^`|}~' do.
v=. <@:v::
end.
v (".(5!:5<'u')-.a.-.":i.10)} ]
}}
and that gets me the same results as in your examples:
(A B) h ((B C)f)
1 2&({ ) 0 1} ]
C h(B +/ .*D)
<@:(B +/ .* D) 2} ]
But is that close enough? I am not sure.
(And, ... since the shallow dereferencing mechanism implemented by
name:: was not available in older releases of J, that would make this
kind of thing more difficult in older J releases.)
Thanks,
--
Raul
On Tue, Sep 14, 2021 at 5:25 PM Jose Mario Quintana
<[email protected]> wrote:
>
> > 0. to 9. and/or _9. would make good additions to language.
>
> Perhaps one should consider that, rightly or otherwise, 0. currently has a
> meaning according to the interpreters (e.g., j902),
>
> 0.
> 0
>
>
> Often I use an adverb (mne) to define undefined names, or redefine existing
> proverbs, as pointers to fetch a corresponding content of a box within a
> state consisting of a list of boxes. For example,
>
> (A B C D)mne
>
> would, as a side effect, define A as 0&({::), ... D as 3&({::). Thus,
>
> C
> 2&({::)
>
> Another adverb (f) allows one to use the proverbs to get multiple boxes
> from the state,
>
> (B C)f
> 1 2&{
>
> and a conjunction (h) allows one to amend the contents of the state in
> terms of the proverbs,
>
> (A B) h ((B C)f)
> 1 2&{ 0 1} ]
>
> or
>
> C h (B +/ .* D)
> <@:(B +/ .* D) 2} ]
>
> The following illustrates their use,
>
> ( S=. 0 ; 1 2 ; '...' ; 1j1*(i.2 3) )
> ┌─┬───┬───┬───────────┐
> │0│1 2│...│ 0 1j1 2j2│
> │ │ │ │3j3 4j4 5j5│
> └─┴───┴───┴───────────┘
>
> C S
> ...
>
> (B C)f S
> ┌───┬───┐
> │1 2│...│
> └───┴───┘
>
> (A B) h ((B C)f) S
> ┌───┬───┬───┬───────────┐
> │1 2│...│...│ 0 1j1 2j2│
> │ │ │ │3j3 4j4 5j5│
> └───┴───┴───┴───────────┘
> C h (B +/ .* D) S
> ┌─┬───┬─────────────┬───────────┐
> │0│1 2│6j6 9j9 12j12│ 0 1j1 2j2│
> │ │ │ │3j3 4j4 5j5│
> └─┴───┴─────────────┴───────────┘
>
> I define tacitly mne, f, and h (moreover, mne f and h themselves are tacit
> entities) via the unorthodox methods using a fork of J which I have
> mentioned in the past. However, I cannot see any reason why mne, f, and h
> could not be defined (explicitly, when necessary) using the latest public
> interpreters.
>
>
> On Tue, Sep 14, 2021 at 1:18 PM 'Pascal Jasmin' via Programming <
> [email protected]> wrote:
> >
> >
> > in jpp project,
> >
> > I use 0. as shortcut for (0 {:: ]) and 1. as shortcut for (1 {:: ])
> >
> > The adverb G =: 1 : 'u {:: ]' is the same.
> >
> > 0.~ or 0 G~ can be used to access fields of x argument.
> >
> > "State of something complicated" can simply be several boxed fields in x
> or y argument.
> >
> > What easy accessors do is also permits "intermediate tacit results" by
> prepending a calculated box to the y argument, with easy unpacking later in
> the verb.
> >
> >
> > 0. to 9. and/or _9. would make good additions to language.
> >
> >
> >
> > On Tuesday, September 14, 2021, 12:06:37 p.m. EDT, Michal Wallace <
> [email protected]> 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
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
