Interestingly, this only applies to undotted argument names: 1+m |value error | 1+ m 1+n |value error | 1+ n 1+u |value error | 1+ u 1+u. 1 + u. 1+v |value error | 1+ v 1+v. 1 + v. 1+x |value error | 1+ x 1+y |value error | 1+ y
That said, ... I would guess that this is a consequence of the extensive changes to name handling required by j903's implementation of namerefs. FYI, -- Raul On Fri, Sep 17, 2021 at 7:23 PM Jose Mario Quintana <[email protected]> wrote: > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
