J is designed with simple rules. These rules are simple to learn, and perhaps difficult to implement. But in a computer language, having users be able to learn the rules is one of the more difficult issues.
Word formation rules include a rule that numbers are formed from certain kinds of characters, with a constraint that the first character after a space needs to be numeric. These are not all meaningful, of course. 1f2 |ill-formed number But that leaves room for future enhancements, if we need to support additional numeric types (perhaps quaternions, for example). Thanks, -- Raul On Wed, Sep 15, 2021 at 8:25 AM 'Pascal Jasmin' via Programming <[email protected]> wrote: > > > Perhaps one should consider that, rightly or otherwise, 0. currently has a > meaning according to the interpreters (e.g., j902), > > Not that long ago, it used to give an error. Never noticed the change. > > A problem that comes up enough to be annoying when defining 3.. or other . : > inflections to numbers is that > > ;: '3.. 2' > > ┌─────┐ > > │3.. 2│ > > └─────┘ > > subsequent numbers is the same word. > > Avoiding this problem, is a pretty easy change to ;: parser, and costs > "nothing" when 3. is a J error, but when 3. was previously valid code, can > create new problems. Still worth the change for me (as a dsl) though. > > > You might prefer your definitions to be > > 1&{::@] > > > This allows intuitive dyadic use case for y, and allows B~ to access x > argument fields. > > > > On Tuesday, September 14, 2021, 07:31:21 p.m. EDT, 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
