Your example: ]'+ F1'swapC +: Does not follow the pattern UW1V because there's no W verb here. Instead, you are using a noun which represents W. So... it's different.
Also, there's no conjunction C which can follow verbs U W V and form a fork without parentheses. If you use parentheses, U W UW2V V would be equivalent to V (U W UW2V). If this is not clear, I guess I should implement UW1V and UW2V so that you can see what I mean. But... is that necessary? Thanks, -- Raul On Sun, Dec 19, 2021 at 4:43 PM 'Pascal Jasmin' via Programming <[email protected]> wrote: > > > There might be just 12 possible variations. Where the 6 additional to the > ones I provided are swapped versions of each of them. (Your other 6 are > triple adverbs, iiuc) > > so U W F1 V swapped is V W F1 U > > I defined swapC in another post which can be used as > > ]'+ F1'swapC +: NB. u F1 forms a conjunction > > +: + ] > > For J, what mostly matters is the combinations of parameters that can be > bound. The adverb that return Conj forms have more flexibility here: > > % F1 > (F1 #) > (+/ %F1) NB. V (#) is remaining parameter to this adverb > (% F1 #) > > > are all partial bindings. The only 2 parameter combination F1 cannot bind to > are U and V, and it also cannot bind to U alone. The case for F0 and F2 is > that they can cover F1's missing combinations. Though only F0 could be > strictly enough to cover the missing combinations from F1. > > F12 is a conjunction that binds W F12 V and returns an adverb that picks up > U. Only 3 bindings are possible. > > (%F12) NB. with V (#) as only parameter to this adverb. > (F12 #) NB. W (%) only available next binding. > % F12 # > > The other 2 conjunctions are needed to cover the other 2 2of3 combinations. > > Conceptually, when making a compound modifier that takes a total of 3 > parameters, an adverb returning conjunction, offers the most flexibility when > 1 or that 1 + 1 of other 2 would be the first bindings. Even if 2 of the 3 > parameters are both equally high likely of being among the first 2 to be > bound, it is still more flexible to use the A->C compound modifier than the > C->A on the off chance that 1st and 3rd might be a preferred pairing order. > > > > On Sunday, December 19, 2021, 01:36:39 p.m. EST, Raul Miller > <[email protected]> wrote: > > > > > > Well, in that case, we should perhaps accompany each of the 'hard way' > variations with a corresponding 'easy way' label for each of the > twelve possibilities. > > For a fork U W V, there are six permutations of the argument verbs > which could be presented to an adverb or conjunction which derives a > fork, so there are 18 possibilities which we might label (with a 1 or > a 2 indicating an adverb or conjunction operator): UWV1 UVW1 WUV1 WVU1 > VUW1 VWU1 UW1V UV1W WU1V WV1U VU1W VW1U UW2V UV2W WU2V WV2U VU2W VW2U > > The "preferred" variants would be UWV1, UW1V and UW2V (preferred in > the sense that these retain verb order when constructing a fork -- > there might be other priorities in some contexts). > > For example: > > UWV1=: {{)a > V5=. 5!:5<'u' > {{)c > W5=. 5!:5<'u' > V5=. n > {{)c > 'W5 V5'=.n > 0!:0 'v=.',V5 > u W5{{ > 0!:0 'u=.',m > u}} v > }} (W5;V5) > }} V5 > }} > > That said, ... purely explicit implementations do not seem to be what > most people would consider to be "easy". They offer a consistent > approach. But that's not quite the same thing. These things are a bit > much to memorize and seem more the sort of thing that a person would > want to look up (if they could figure out how to look for them). > > Also, conceptually, each of the 'hard way' mechanisms might also be > accompanied by step-by-step equivalences, working through the parsing > and evaluation of some example fork. If the example fork involves > compound verbs, (like the range fork: >./ - <./) that would > complicate the focus on parsing. So, perhaps, the example fork would > only use primitive verbs. I imagine (*: >. %:) or ($ ; ,) would serve > well here. Examples are valid only after we have the implementations. > But this kind of thing helps convey the constructs to other people who > have their focuses on slightly different issues. > > But the problem with showing the intermediate steps in fork > construction for the "easy way" would be the verbosity of the > intermediate steps. > > Still, ... we can show that an example fork construction technique works: > > $ ; , UWV1 > $ ; , > > ($ ; ,UWV1) i.2 2 > +---+-------+ > |2 2|0 1 2 3| > +---+-------+ > > However, since each step is a "baby step", it's incredibly easy to > skim over the steps and then wonder what it was that you missed. So > even with examples, this would wind up being something to be digested > over an extended period of time. > > Conceptually, each of the 18 variations of a fork construction > operator should be implementable using the 'hard way'. But it's not > clear that those implementations would all be more concise than the > 'easy way' implementations (with redundant white space removed when > measuring size of the implementation). > > Thanks, > > -- > Raul > > On Sun, Dec 19, 2021 at 10:11 AM 'Pascal Jasmin' via Programming > <[email protected]> wrote: > > > > The big feature of the new modifier trains is in creating tacit > > conjunctions. > > > > > F12b=: {{u`v`}}`:6 > > > > in older versions of J, a modifier returning an adverb was the only "easy" > > way of creating compound modifiers. Your example is such an "easy way" of > > returning a modifier. The "hard way" is having to build a string (double > > quoting if one liner) while inserting any functions/nouns passed into the > > first modifier into the return modifier and then doing (n : ) on the string. > > > > F1 F2 F3 are examples of an easy way to return a conjunction (not possible > > before). And the conjunction examples (F01 F02 F12) are "tacit at heart". > > The 2 : 'C' trick is used return adverbs. It is easy even if it requires > > using an explicit term, because it is short, not building a string, not > > using a named function dependency. > > > > In previous J versions, I made these frameworks with "strand" double/triple > > adverbs: Only adverb trains existed, and adverbs conveniently consume > > entire verb phrases (u argument taken in whole while v argument to > > conjunction is only a word). Disadvantages included difficulty in partial > > bindings of compound/double adverbs, and certain quirkiness with chaining > > multiple compound adverbs. This is a big enhancement for me. > > > > > > On Friday, December 17, 2021, 10:00:21 p.m. EST, Raul Miller > > <[email protected]> wrote: > > > > > > > > > > > > But wait, there's more... > > > > For example: > > F12b=: {{u`v`}}`:6 > > > > The name is completely arbitrary (since I do not understand your > > F0..F12 naming scheme). But the behavior of F12b is like the behavior > > of F0 and/or F02. > > > > FYI, > > > > -- > > Raul > > > > > > On Fri, Dec 17, 2021 at 9:45 PM 'Pascal Jasmin' via Programming > > <[email protected]> wrote: > > > > > > J has gotten some powerful tools in 903 for making compound modifiers > > > (modifiers that return other modifiers) and some interesting parentheses > > > eliminations > > > > > > The following 6 modifiers create forks. The 3 Fm ones are adverbs that > > > return conjunction when n indicates the fork tine that is fixed by the > > > adverb. The Fmn ones are conjunctions that fix positions m and n to > > > return an adverb that will fill the remaining position. > > > > > > cocurrent 'z' > > > > > > F0 =: 1 : 'u ` ` `: 6' > > > F1 =: 1 : '[. u ].' > > > F2 =: 1 : '` ` u `: 6' > > > > > > > > > F01 =: ((` (2 : '`')))(`:6) > > > F02 =: 2 : '(u`)(`v)(`:6)' > > > F02 =: ( ([.(2 : '`')) (2 : '`' ].) ) (`:6) > > > F12 =: (2 : '`' `) `: 6 > > > > > > > > > The conjunction forms can all be made tacit other than the (2 :'`') bits > > > that are used to "fool" CC trains into forming adverbs. I withdraw my > > > criticism of CC, because the trick of 2 :'C' in place of a conjunction is > > > a very flexible short and readable way of making CC (and other modifier > > > trains) return compound modifiers. > > > > > > The facit version of F02 is ((CC)(CC))A -> CA -> (AA)A > > > > > > F1 and F12, and F0 and F02 have same binding order with 3 parameters. > > > (and F2 would match a swapped F12, named F21 but not provided above) > > > > > > These compound modifiers reduce parentheses use, while permitting more > > > flexible composition. > > > > > > > > > In terms of choosing an F shadow name, F1 or F12 seem like the best > > > choices, because they both keep the same fork order. > > > > > > +/ %F1 # > > > > > > +/ % # > > > > > > F1 has the advantage of binding any single adjacent parameter while > > > keeping order of remaining parameters, and can also do this: > > > > > > #(+/ %F1) > > > > > > +/ % # > > > > > > +/ % (F1 #) NB. A V form > > > > > > F12 has less binding flexibility, but because it is an "original" > > > conjunction, it binds its right parameter, and so the whole fork becomes > > > a parameter to any other modifiers > > > > > > > > > +/ % F12 # "1 > > > > > > (+/ % #)"1 > > > > > > +/ % F1 # "1 > > > > > > +/ % #"1 NB. since F1 is adverb, w u F1 v (AA)CvAAAA -> w (u F1) ((((v > > > (AA)Cv)A)A)A)A). ie. v will bind with expression to its right "normally" > > > as if it were a u parameter. > > > > > > > > > F =: F12 NB. instead of F =: F1 is chosen for composability, saving 2 > > > chars instead of 1. F1 still very useful. > > > > > > compositions with F1 can choose which adverbs/modifiers operate on the v > > > parameter and which operate on full fork > > > > > > +/ % (F1 (<.@:)) #"1 > > > > > > <.@:(+/ % #"1) > > > > > > #"1(+/ % F1) (<.@:) > > > > > > <.@:(+/ % #"1) > > > > > > #(+/ % F1) (<.@:)"1 > > > > > > <.@:(+/ % #)"1 > > > > > > > > > +/ % F # (<.@) = F] # F] (#@) NB. count of items that are equal to floor > > > of average > > > > > > #@((<.@(+/ % #) = ]) # ]) NB. much easier to type out/read. > > > Parenthesized expressions are short > > > > > > ] +/ %(<.@) F # = F] (F2 (#@)) #~ NB. same expression but swapped term > > > positions, and adverb move > > > > > > #@(] #~ (+/ <.@% #) = ])#@(] #~ <.@(+/ % #) = ]) NB. minimal edit effort. > > > > > > A guideline for which of the 6 fork generators to use is to leave the > > > most complicated term of the fork as the leftmost parameter. Though > > > there is much more flexibility than in previous J versions > > > > > > ] = F1 +/ % F # NB. using F1 allows for "complicated" right part > > > > > > ] +/ % F # (F2"1) = NB. complex part in u (of F2) > > > > > > (] = +/ % #)"1 > > > > > > ] +/ % F # F01 = "1 NB. similar but may have reading preference. > > > (F01"1) also legal > > > > > > ((+/ % #) = ])"1 > > > > > > > > > > > > On Tuesday, December 14, 2021, 12:53:38 p.m. EST, 'Pascal Jasmin' via > > > Programming <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > Making an ammend conjunction patterned around the u`v`]} form but where u > > > is a function of the selected (v) items of y > > > > > > version 1 > > > > > > 13 - ((2 : '[ u v { ]' ` ].) (`])}) 1: i.5 > > > > > > 0 12 2 3 4 > > > > > > There appears to be a rule that modifier trains that are longer than 3 > > > "tines" will be grouped from left to right in 3s > > > > > > above is (C C C) A A . This allows fewer parentheses since they will be > > > auto added > > > > > > 2 : '[ u v { ]' ` ]. (`])} > > > > > > (2 : '[ u v { ]' ` ].) (`]) (} ) > > > > > > and even > > > > > > 2 : '[ u v { ]' ` ]. `]} NB. C C C C V A -> ((C C C) C V) A -> CA = > > > rational pre-903 modifier trains. > > > > > > ((2 : '[ u v { ]' ` ].) ` ])(} ) > > > > > > version 2: enhance the ammend conjunction to work monadically. u dyadic > > > function called monadically has access to both selected items and whole > > > list as right arg. > > > > > > extending to right end without parens works (adding ~ reflect, and > > > switching some internal [ ]) > > > > > > 2 : '] u v { [' ` ]. `] }~ NB. CAA > > > > > > ((2 : '] u v { [' ` ].) ` ]) (} ) ~ > > > > > > but this lack of parentheses elegance is only due to CCV -> CA > > > > > > if instead, this is written as CAAA, it becomes (CAA)A, and still works > > > > > > 2 : '] u v { [' ` ]. (`[) }~ > > > > > > ((2 : '] u v { [' ` ].) (`[) (} ))~ > > > > > > 13 -(2 : '] u v { [' ` ]. (`[) }~) 1: i.5 > > > > > > 0 12 2 3 4 > > > > > > ABER = Always be extending right. You can parentheslessly extend a > > > modifier to the right with A or C (u = v or n) > > > > > > version 3: allow v (selection verb) to be a noun by adding "_ modifier to > > > "selection tine" of } > > > > > > our versions so far are in C C C C V A A format, and we need to modify > > > the 3rd C from left. This won't work > > > > > > 2 : '] u v { [' ` ]. "_ > > > > > > > > > because that is (C C C) C N which applies "_ to whole expression instead > > > of just middle tine of } gerund. so C C (C "_) is what we are looking for > > > > > > 2 : '] u v { [' ` (]."_) (`[) }~ > > > > > > ((2 : '] u v { [' ` (]. " _)) (`[) (} ))~ > > > > > > 13 -(2 : '] u v { [' ` (]."_) (`[) }~) 1 i.5 > > > > > > 0 12 2 3 4 > > > > > > version 4: replace the explicit conjunction left part with a tacit one > > > > > > sketching it out before worrying about "AC problems" or parenthesing, > > > > > > [` ` `{`[ > > > > > > (([ ` `) ` ({ )) ` [ > > > > > > appears correct because UCC does what AC "should" do. There is a bug > > > with our version 3 enhancement. A noun argument will blow up the "` > > > trains" > > > > > > -(]` ` `{`[ `: 6) 1: > > > > > > ] - 1: { [ > > > > > > ar =: 1 : '5!:1 <''u''' > > > > > > > > > and CCA can replace our dangling ` (C) > > > > > > > > > -(]` ([. ` ar) `{`[ `: 6) 1 > > > > > > ] - 1 { [ > > > > > > amend =: ]` ([. ` ar) `{`[ `: 6 ` (]."_) `[ }~ > > > > > > 13 - amend 1 i.5 > > > > > > 0 12 2 3 4 > > > > > > This seems very clean only because uCC behaves as the rational AC. If > > > you make the mistake of parenthesing the initial (]`) then transforming > > > to ACA format is only manageably dirtier because the starting state is > > > clean > > > > > > - ((]`) ([. ` ar) ]. `{`[ `: 6 ` (]."_) `[ }~) 1 > > > > > > (] - 1 { [)`(1"_)`[} ~ > > > > > > > > > > > > > > > > > > > > > On Sunday, December 12, 2021, 02:15:03 p.m. EST, 'Pascal Jasmin' via > > > Programming <[email protected]> wrote: > > > > > > > > > > > > > > > > > > I'd like the following changes to new modifier trains in priority order: > > > AC -> uACv > > > CC -> (uC1v)C2 > > > u`n and m`v producing gerunds instead of errors when n or m is unboxed > > > and not '' > > > > > > J is a powerful language in large part due to its existing modifier > > > support. It allows easy composition of functions and modifiers. The new > > > trains, especially ACA and CA are a significant enhancement of that > > > composition power. These new/old trains also make writting compound > > > modifiers much easier. > > > > > > Thank you to J team for reviving the old trains. > > > > > > With J's strong capabilities for composition, the primary purpose of > > > writing a modifier is an expectation for general (re)use. And the value > > > of the whole system is in the ease of composition and editability. > > > > > > If you want to create the (current) behaviour of AC, you can easily write > > > 1 : 'uACu' or tacitly, ((A C [.)a:) . And this, likely very rare use > > > case, is then available for full composability by you and users. > > > > > > Composability means 2 things. Easy function composition, but also, an > > > easily editable writing process. > > > > > > +(``:6)# > > > > > > + # > > > > > > The current way to extend this CA (CCV -: CA) with adding say a / > > > modifier to u is to shoehorn the expression into ACC format: (AC].) > > > > > > + (/(``:6)].)# > > > > > > +/ # > > > > > > > > > That extra ]. all the way at the "other end (right)" of the C part in AC > > > is a needless "nightmare"/composability obstrction in comparison to > > > "forcing extra steps" for the less useful current AC definition. > > > > > > One improvement would be to define AAC (currently undefined) as u(AA)(Cv) > > > and AAAC as (AA)AC because then composing an adverb to left of modifier > > > train would only require an extra annotation (A ]: C) that does not > > > require cursoring over and may also not require an abundance of parens. > > > There is a readability problem as well when the }bookkeeping annotation" > > > ]: or ]. is not next to the leftmost modifier > > > > > > Reading a modifier must be done left to right. The right parts compose > > > on the results of the left parts. Calculating the order (number of > > > parameters) of a modifier both mentally and mechanically is easier when > > > most, and the simplest (AC CC ACA and CA) are all conjunctions until > > > observed verb/nouns bind them. When encountering left to right AC, > > > having to mentally or mechanically compute/find whether there is a ]. in > > > appropriately parenthesized location is taxing and distracting. > > > > > > CC as a hook generator is marginally useful. (``:6) would do the same, > > > and if ` produced gerunds with m`v and u`n for unboxed and non empty m > > > and n, then producing (u n) from CC "replacement" is also easy. A user > > > defined conjunction ti can replace `, but it requires explicit code that > > > pollutes display on partial bindings. > > > > > > +`(1 ar)`] creates a display ugliness that +`1`] would not. > > > > > > it might also be worth enhancing } such that > > > > > > +`(1 ar)`]} > > > > > > |domain error > > > > > > didn't happen, and +`1`]} would be legal and would display as written. > > > }(amend) is a critical language function that could be easier to use. > > > v0`v1`v2 could also be a monadic version of amend. > > > > > > The proposal for CC -> ((u C1 v)C2) supports the need for a > > > modifier/modifier train to have more than 2 parameters. Proposed CC > > > would have order of 3. > > > > > > A current workaround for achieving the desirable behaviour is to create a > > > CA train with the compound modifier > > > > > > CasA =: 1 : ' 1 : ('' u '' , m ) ' > > > > > > > > > # +/( ` ('`'CasA)) % > > > > > > ┌───────┬─┬─┐ > > > > > > │┌─┬───┐│%│#│ > > > > > > ││/│┌─┐││ │ │ > > > > > > ││ ││+│││ │ │ > > > > > > ││ │└─┘││ │ │ > > > > > > │└─┴───┘│ │ │ > > > > > > └───────┴─┴─┘ > > > > > > to make a train out of the gerund (`:6) the "easiest" solution is to > > > modify the CA train to CAA, but the "most appropriate"/extensible > > > solution is to treat (`:6) as an "optional"/end transformation function > > > to be tacked on or removed for debugging or inserting further modifiers > > > in between > > > > > > # +/( ` ('`'CasA(`:6))) % NB. easy less extendible way > > > > > > +/ % # > > > > > > # +/(( ` ('`'CasA))(`:6)) % NB. extensible but requires extra parentheses > > > with cursoring around to envelop previous expression > > > > > > +/ % # > > > > > > extending the function using current AC workaround to put the / adverb > > > inside the modifier instead of the caller's responsibility: > > > > > > # +(( (/ ` ]:) ('`'CasA))(`:6)) % > > > > > > +/ % # > > > > > > as proposed for CC this core would become (` `) and the alternative for > > > train formation ((` `)`:6) is much neater starting point from which to > > > insert additional expansions/modifiers. The enhanced modifier above > > > becomes (((/`)`)`:6) > > > > > > Making general modifier composability "the bias" is a worthwhile focus > > > of the language. Shortening the space between parentheses and reducing > > > the total number means improvements in writability and readability, and > > > extending the expression complexity that is mentally manageable. > > > > > > > > > On Tuesday, October 5, 2021, 12:24:44 p.m. EDT, Pascal Jasmin > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > HR: I found the production (A C)->((x A) C x) useful enough in my work > > > that I gave it a name, the adverbial hook. > > > > > > > > > One way to keep this production, which I still fail to see as "useful > > > enough", while enhancing composability of modifier trains is defining > > > > > > AAC -> u AA(Cv) > > > > > > implying that > > > > > > AAAC -> (AA)AC and A(AAC) -> (AA)AC > > > > > > Parenthesized (AC) can retain your quirky production. > > > > > > if you have an A and a C that you wish to "compose intuitively", ]:AC has > > > better future composability than the ACA transformation of AC]: due to > > > parentheses explosion described below. > > > > > > > > > A yet to mention advantage of composability is the ability to test > > > individual modifier trains before combining them simply. The AAC and > > > ]:AC proposals would do this, in a way that shoehorning a modifier into > > > ACA form does not. ie. composing a modifier train to the left of ACA > > > requires a new shoehorning into a new ACA structure. > > > > > > Assuming the above is sensible, and in the spirit that more trains are > > > good, there are a couple of other "smelly" current train defintions. > > > Smelly for reusing arguments: > > > > > > ACC -> uA C (u C v) > > > CCA -> (u C v) C (vA) > > > > > > it is worth noting that current AC could also be written as ((AC[.)a:) > > > > > > but some productions that are missing that would include a CC component > > > in a train are > > > > > > (uC)(vC) > > > (Cu)(Cv) > > > (uC)(Cv) > > > (Cu)(vC) > > > > > > ACC and CCA could cover 2 of them. CAC could cover a 3rd. > > > > > > > > > On Monday, October 4, 2021, 08:44:11 p.m. EDT, 'Pascal Jasmin' via > > > Programming <[email protected]> wrote: > > > > > > > > > > > > > > > > > > I have to be repetitive in first part of response because it seems to > > > have been missed in later discussion > > > > > > ``:6 is all that is needed to produce a hook. > > > > > > a replacement to ` that forms gerunds out of m`n or m`v or u`n is needed. > > > I call that replacement "ti". > > > > > > That is needed for the u n execution example of your CC. The only reason > > > you would ever need a modifier to execute u n (or y) is if u returns a > > > string that needs to be processed by another modifier (such as 1 : or 3 > > > : ) in order to produce a function. > > > > > > Therefore all uses of implemented CC are served by ti(`:6)(optional extra > > > Adverb to process a noun result) > > > > > > > > > USE CASE (as requested) > > > > > > All 902 modifier trains are composable by simple juxtaposition. AAA and > > > A compose with whichever is positioned on the left will send its result > > > to the one on the right. Composability is high value awesomeness! > > > > > > My CC proposal keeps that composability for the new enhanced modifier > > > trains that include CA and ACA (both conjunctions) > > > > > > forcing (AC[:) as a replacement for what should just be AC harms > > > composability as well: > > > > > > A (AC[:) has to be written as A (AC[:) [: . Adding a further A to left > > > means (A (A (AC[:) [:) [:) if as an example all of the As and ACAs were > > > named, and you couldn't just go inside the ACA to do ((AAA)C[:) > > > > > > I don't believe conjunction reflexitivity is worth the composability > > > nightmares. > > > > > > > Reducing parentheses is not a laudable goal; in fact, I see it as the > > > opposite. The train A A C should, if possible, mean something different > > > from (A A) C because Why have two ways to say the same thing? > > > > > > > > > AAC is not defined, btw, but if it were I would strongly hope that it > > > were (AA)C]: ie what (AA)C and AC should be. > > > > > > It is a respectable philosophy to have unique trains that force explicit > > > parentheses. I would prefer fewer parsing rules with auto pairing of > > > parameters for the pure blissful cleanliness of it all (but not insisting > > > on the full purity extreme). Your view forces a lot of memorization that > > > might have been an important factor in the original decommissioning. > > > > > > > > > > > > On Monday, October 4, 2021, 06:05:47 p.m. EDT, Henry Rich > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > The discussion is moving toward the polemic and unhelpful. I write to > > > try to suppress suggestions that have no hope of being implemented soon. > > > > > > 1. Reducing parentheses is not a laudable goal; in fact, I see it as the > > > opposite. The train A A C should, if possible, mean something different > > > from (A A) C because Why have two ways to say the same thing? We are > > > trying to define a grammar with NO reserved words except parentheses; > > > perhaps only Ken could have attempted it; there are just a handful of > > > productions to define; they should be as powerful as possible, with as > > > little duplication as possible. > > > > > > 2. I found the production (A C)->((x A) C x) useful enough in my work > > > that I gave it a name, the adverbial hook. > > > > > > 3. (C C) -> ((u C v) C) is a drastic change to the language. It consumes > > > two words and creates something that consumes one or two more words. Is > > > it brilliant? Is it the camel's nose in the tent? I personally think > > > it raises a stench to the nostrils of the Almighty. I could be wrong. > > > But anyone suggesting such a fundamental change must arrive first with > > > SHORT EXAMPLES showing why the language should consider such forms, > > > which will be so unfamiliar to the J programmer. If the knowledgeable J > > > community is convinced, we can consider whether the forms should be > > > implemented. > > > > > > A couple of users (including me) suggested (C0 C1)->((u C0 v) (u C1 > > > v)). Why? Because it allows > > > * easy production of hooks, with V ([. ].) V > > > * execution of verbs, with V ([. ].) N-phrase > > > > > > That's a pretty good argument, SUPPORTED BY EXAMPLE. Hooks are important. > > > > > > I am very reluctant to make changes that don't have demonstrated > > > benefits, being a disciple of Omar: > > > > > > O take the cash in hand and waive the rest; > > > Ah, the brave music of a /distant/ drum! > > > > > > Henry Rich > > > > > > > > > On 10/4/2021 4:33 PM, 'Pascal Jasmin' via Programming wrote: > > > >> That said, this was also a syntax error when we did not have > > > > conjunction trains. So I am not sure why it should be an important > > > > issue now. > > > > > > > > if you stick to old permissible AA...A trains then you don't need to > > > > "over" bracket (AA..A) > > > > > > > > for CAA..A you also don't need to bracket (for practical purposes) > > > > > > > > for AA..ACA, you do need to over bracket the left part. > > > > > > > > > > > > There are new powers that allow including unbound Cs inside adverb > > > > trains. That is awesome!!! The disadvantage of imposing tedium on > > > > these new powers is greater than the advantage of not double typing out > > > > u in uCu, in my opinion. > > > > > > > > > > > > On Monday, October 4, 2021, 04:20:13 p.m. EDT, Raul Miller > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hmm... > > > > > > > > Conceptually speaking, the A A C A syntax error could be eliminated > > > > without the addition of any new parsing rules, if A A C would > > > > translate to two parse elements (combining the two adverbs and putting > > > > the C back as-is). > > > > > > > > That said, this was also a syntax error when we did not have > > > > conjunction trains. So I am not sure why it should be an important > > > > issue now. > > > > > > > > I also don't know if there are other implications. I haven't thought > > > > about it that much. > > > > > > > > Are you aware of other important cases? > > > > > > > > Thanks, > > > > > > > > > > > > > -- > > > This email has been checked for viruses by AVG. > > > https://www.avg.com > > > > > > ---------------------------------------------------------------------- > > > 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 > > ---------------------------------------------------------------------- > > 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
