Thanks, Elijah! This was very helpful. I think I was sort of hallucinating that the mere presence of [. and ]. would change the meaning of the entire train, the way the mere presence of u and v changes the meaning of a direct definition, but of course that's not the case.
I am going to have to meditate on (].~)@: for a while.. I see it, but I don't quite believe it. :D Thanks! On Thu, Apr 21, 2022 at 6:30 AM Elijah Stone <elro...@elronnd.net> wrote: > On Thu, 21 Apr 2022, Michal Wallace wrote: > > > I then thought that replacing u => [. and v => ]. would let me remove > the > > double curlies, but clearly this is the wrong idea: > > > > AA =: ([. @: ].) ]. ] > > _: AA (3 AT) ;/i.10 > > +-+-+-+-+-+-+-+-+-+-+ > > |0|1|2|3|4|5|6|7|8|9| > > +-+-+-+-+-+-+-+-+-+-+ > > > > I don't really understand what it's doing but I'm (mistakingly?) > imagining > > that it's a fork. > > Let's break it down. Starting inside the parens: ([. @: ].) is a train of > three conjunctions; that is a conjunctive fork. The rule is: u(C0C1C2)v > is > (uC0v)C1(uC2v). C0 is [., C1 is @:, and C2 is ]. . u[.v is u (by > definition), and u].v is v (by definition). So u([. @: ].)v is > (u[.v)@:(u].v), which is u@:v. Which means that [. @: ]. is just an > obfuscated way of writing @:, similar to to the verb fork [ + ] . > > That means your AA definition is equivalent to @: ]. ] . @: ]. ] is also > a > conjunctive fork. It is not CCC, but CCV; the right tine of the fork is > constant. This is analogous to an NVV verb fork, where the left tine is > constant. The rule here is: u(C0C1V2)v is (uC0v)C1V2. C0 is @:, C1 is > ]., > and V2 is ] . So, regardless of what u and v are, we will get (u@:v) ]. > ], > which is just ] . > > A conjunctive fork _is_ a fork, but there is no reason to believe it will > _produce_ a verb fork. > > > If it were a fork with ] on the right, I think I should be able to > rewrite > > it like so: > > > > AA =: ].~ ([. @: ]) > > > > But this gives a syntax error.... Why? > > This is very close to working. The issue is that when producing trains, > the > parser tries to eat as many terms as it can. So for instance, in a > regular > verb train, it could have been defined that f g h is a two-level hook, > equivalent to f (g h). But then we wouldn't be able to make forks. So we > say > that a 3-train will be formed whenever there are at least 3 terms > available; > and we will only form a 2-train when we have no other choice. Your > definition > is ]. ~ ([. @: ].), that is CAC; and no meaning has yet been assigned to > CAC, > so it is a syntax error. But you want (CA)C. Parenthesizing as (].~) ([. > @: > ].) gives a result that works! (And this is effectively the same as the > solution of (].~) @: I gave; I missed this before, when I was skimming.) > > > > So okay, if I just put ] back in on the left: > > > > AA =: ] ].~ ([. @: ].) > > _: AA (3 AT) ;/i.10 > > _ > > Now you are running into grouping issues again. I don't quite understand > the > parsing rules for longer trains--it is simply left-to-right in simple > cases, > but more interesting in other cases; pascal has a wiki article about > it--but > in this case it does work out nicely left to right. We can ask the repl > how > this sentence parenthesises: > > AA =: ] ].~ @: > AA > (] ]. ~)@: > > We had VCAC, and it was grouped as (VCA)C. VCA is an adverb; so the > sentence > as a whole is AC, which is also an adverb; not a conjunction. So it is > not > surprising that you got nonsense results here :) Left as an exercise to > you > is to figure out exactly why you get the result that you do. > > In general, I suggest referring to the table at > https://code.jsoftware.com/wiki/Vocabulary/fork#invisiblemodifiers at > frequent > intervals, and querying parenthesisation at the repl. > > -E > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
