@Pascal Thanks for going out on limb and starting this discussion. Personally, I find the current modifier train parsing table relatively intuitive, but you definitely got me wondering *why* I do. FWIW, the proposal you share seems to mostly just save parentheses, which at first blush, feels to me like it hamstrings the compositional power of trains, kind of like if forks were defined as [x] (f g h) y <=> [x] (f (g (h y))) or some such.
Anyway, I haven't given this all the thought it deserves, but I just wanted to throw out an impression and say thanks for giving me something deep to chew on. It will take time to fully digest. Cheers, Pascal Jasmin <[email protected]> wrote: > > My proposal for (C V C) is (C V) C which matches the A C train I agree with. > End result is u (C V) C v which is equivalent to either u C V C v, or (u C V) > C v or u (C V) (C v) > > > > > > On Monday, September 27, 2021, 05:59:20 p.m. EDT, Elijah Stone > <[email protected]> wrote: > > > > > > On Mon, 27 Sep 2021, 'Pascal Jasmin' via Programming wrote: > > > (C V C) conj -> (u C V C v) ie. interpreted the same way as if terms had > > been written inline > > This is not how any other train is interpreted (except for pure adverb > trains); forks are already there, and in particular N V V forks, so it > would be inconsistent to behave otherwise here. > > > -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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
