I wrote,

> Of course, the mechanisms are different, and usual naming restrictions
that apply only to explicit definitions might interfere; for example,

Incidentally, I noticed an apparent j903 change in (a fresh session)
behavior,

   1 + a
1 + a

is fine; however,

   1 + x
|value error
|   1+    x

It seems related to the names associated with explicit arguments.  I have
just been running the DLL without a full installation.  I do not think it
matters but perhaps someone would like to confirm this.


On Wed, Sep 15, 2021 at 5:15 PM Jose Mario Quintana <
[email protected]> wrote:
>
> > 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).
>
> Of course, the mechanisms are different, and usual naming restrictions
that apply only to explicit definitions might interfere; for example,
>
>    u mne
> |domain error: mne
> |   0    =:0&{::
>    n mne
> |value error
> |       n mne
>
> Another aspect that I did not mention is that my version of mne actually
produces a result,
>
>    (A B C D)mne
> ┌───────┬───────┬───────┬───────┐
> │0&({::)│1&({::)│2&({::)│3&({::)│
> └───────┴───────┴───────┴───────┘
>
> That is, the (illegal) list of the boxed pointer proverbs; its legal
counterpart would be the corresponding gerund.  This result is occasionally
useful, see my forthcoming reply to a comment made by Pascal
>
> > and that gets me the same results as in your examples:
> >
> > Still, ... I could define h as
> >
> > h=:{{
>
> > ...
> > But is that close enough? I am not sure.
>
> It seems to me that you guessed correctly (even using only the
information I provided).  There is also another difference between our
versions of the adverb f which I did not specify.  When f's argument is a
single proverb then its behavior is similar to that of h's; namely, its
product is the same as the proverb (e.g., B f is the same as B)
>
> (In addition, in my versions of f and h, indices can be used also in
place of pointer proverbs (e.g. (0 3)f is the same as (A D)f; however, that
is just icing on the cake.)
>
>
>
>
>
>
> On Tue, Sep 14, 2021 at 7:42 PM Raul Miller <[email protected]> wrote:
> >
> > 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to