Talk:Vocabulary/ModifierTrains

Proposal to remove the documentation for the auto-verb-train-formation (AVTF) grouping rule

I propose effectively removing consideration of the AVTF rule by means of requiring a simple parenthesization scheme for verb/noun phrases.

Motivation:

Costs of keeping the AVTF documentation

• Inelegance. The modifier train grouping rules just feel big, unwieldy, messy, and ad-hoc, burdened by exceptions and explanations. Ad-hoc in the sense that (A/C)C(V/N) defer to the greed rule, while others do not, and that formation of VC and AV will preempt that of VC(A/C) and AVV respectively, when left side has odd number of V's, but the 2-trains CV and AC will never form from CVVV or ACVVVV respectively, meaning the relation between VC and VC[A/C] is different from the relation between [A]C and [A]CV. All of this asymmetry would disappear by removing the AVTF rule, as compound 2-trains would always have to be parenthesized to be grouped as such.
• Currently the axioms concerning the verb-train-forming rule in MT's are complex to document, requiring countless examples in order for the reader to even begin to get comfortable with some of them (the small subset that is currently documented).

And this is the case even without the actual nuances, like:

   (C V V) V V V C A            
(((& V V) V V) V &)/          NB. why this and not ((& V V) (V V V) &)/ ?
      C C C V V V V V C A     NB. here's CCC…
(((& & &) V V) (V V V) &)/
      C C A V V V V V C A     NB. with odd number of V's, CCA <--X--> CCC even though both derive a C??
((& & /) (V V V V V) &)/
      (C C C) V V V V V C A   NB. CCC… <-----> (CCC)… as expected
(((& & &) V V) (V V V) &)/
      (C C A) V V V V V C A   NB. CCA… <--X--> (CCA)… ?? 
(((& & /) V V) (V V V) &)/
      C C C V V V V V V C A   NB. but with even number of V's, CCC and CCA group the same way??
((& & &) V (V V V V V)) & /
      C C A V V V V V V C A   NB. but with even number of V's, CCC and CCA group the same way??
((& & /) V (V V V V V)) & /

If we're not prepared to explain these nuances in the documentation, then we should preclude them from coming up.

• Modifier trains are straightforward to compose, yet their general use falsely appears absurdly complicated due to the (optional) considerations invoked by omitting parentheses. The very presence of such a long list of parsing examples unavoidably calls inordinate attention to them, making it seem important/necessary for one to consider them, and thus needlessly deterring the would-be general-tacit programmer. (Speaking from my own personal experience.)
• The AVTF rule has unintuitive behavior:

   @ + - % $ #
(@ + -)(% $ #)

If you want to code a hook of two forks ({{(u@v + -)(% $ #)}} in a direct definition, or just e.g (*@^. + -)(% $ #) if your verbs aren’t variable), you couldn't write it without parentheses. So why would we be able to omit them within a modifier train? Writing C V V V V V to denote a hook of two forks is bad practice anyway due to its obfuscation. Similarly for the NVVN in NVVNCAVV, which evaluates as if it were parenthesized. (That appears to be why VN and NVN are in the table, by the way: as the left tine of a modifier train, they're grouped as a unit without needing parentheses. Pretty weird.)

Benefits of removal of documentation

1. The resulting single rule (group in 3’s from left) would be just as simple and elegant as that for normal verb trains, and moreover would be symmetric to it.
2. If the MT grammar's elegance were no longer wrapped in a complex, ad-hoc bundle of grouping-rule examples, then for the most part, I think we'd feel much less of a need to hide it from non-advanced J'ers. And then those like myself who prefer writing most modifiers tacitly can learn to do so much earlier and much more easily.

Proposed solution

The real proposed solution is to dispense with documenting the AVTF behavior whatsoever, instead pointing the user to a simple parenthesization rule that results in the pure “group in 3’s from left” behavior.

In the parsing section of the Modifier Trains ancillary page, just say:

1. Within modifier trains, sequences of more than two successive non-parenthesized verbs/nouns should not occur.
   1. If this rule is not followed, the modifier train will be grouped according to behavior that has been deprecated due to its inordinate complexity.
2. Provided that the prior rule is adhered to, longer modifier trains group in 3's from the left.

NB. Grouping in 3's from left:
   & & / & + +      NB. even number of words
((& & /) & +)+
   & & / & & + +
((& & /) & &) + +   NB. odd number of words

So if you want:

• (CCA)CA --> parens not needed: CCACA
• (CVV)CA --> parens not needed: CVVCA
• (CVV)VV --> parens needed; CVVVV has more than two successive V's
• (NVN)C   --> parens needed; NVNC has more than two successive V/N's

And that's it. This would be the full extent of the parsing documentation; these would be the only examples needed.

Now, even better would be to just say that they group in 3's from the left, and that's it. This would require removing the AVTF behavior from the language itself. But AVTF is a haphzard set of emergent behaviors resulting from virtually all of the rules in J’s parsing table; it is not its own independent rule. So removing the AVTF behavior would require rewriting the parser to look at the entirety of every sentence or phrase to see whether it’s a modifier train, and thus determine whether to parse it from the left or right. This would be wasteful. But the proposed documentation solution is simple and effective.

Conclusion

With the proposed removal of AVTF consideration, parsing MT’s would become simple. Just as with verb trains, beginners who encounter MT’s too early will nevertheless likely realize that J is an elegant, carefully designed language, and may be curious to explore tacit modifiers eventually, as opposed to feeling deterred. The proposed change is something I personally would've found very helpful and clarifying.

--Cameron Chandoke (talk)

---

The examples/questions above are now explained in an essay. The answers are far too involved to be wrapped into a few parsing rules specific to MT’s, however. --Cameron Chandoke (talk) 23:14, 17 October 2023 (UTC)