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
