Henry wrote: > but not something we want a naive user stumbling across when they look up Forks.
I agree. (Though I've always felt that a naive user who strays into: *More Information* – and beyond – deserves all he gets.) But the whole sub-page: "Modifier trains" abuses: https://code.jsoftware.com/wiki/Vocabulary/HowNuVoc#Structure_of_a_Primitive-Page This makes it far more opaque than it need be. How can we expect a novice user to follow it if we throw away the signposts and landmarks? ++ For one thing, there is no *Down to:* in the Navbar. So the sub-page is buried if you don't know it's there, unless you reach it from the NuVoc portal. ++ For another, there is no logical justification for having more than one banner to a page, except to document Monad and Dyad of the same primitive. Or (like F. F.. F.: etc) a family of primitives thought best to describe with a single page. (But then why don't i. and i: share a page?) Now NuVoc has problems documenting modifiers. Problems magnified with "invisible modifiers". (…Invisible primitives? Cripes! What else can be lurking unseen in an innocent-looking J sentence?) Since NuVoc specifically documents J *primitives*, must an invisible primitive have an invisible page? Other modifiers, e.g. (:), overcome the problem by extending across more than one page. Why not here? The it will become obvious that the wonder new invisible primitive: "modifier trains" lacks these mandatory parts (copy-pasted from the link above): - Rankbar - Introductory paragraph - Section: *Common Uses* - Section:* Related Primitives* …plus optionally: *More Information* -under which IMO the whole of the existing treatment belongs. Alternatively, as Henry suggests, move the whole treatment into an Ancillary Page, for which the novice expects a less structured format (i.e woollier, more muddled). It can then be linked from both Hook and Fork. On Tue, 21 Dec 2021 at 03:44, Henry Rich <[email protected]> wrote: > The text starting with 'Longer forks/trains' is a welcome addition, > though I find the long list of examples at the bottom of the page needs > some explanation or perhaps formatting into a table. > > BUT: I think this would be better as an Ancillary Page, linked by the > fork page and referred to in the list of pages at the bottom of the main > NuVoc page. > > It is an exotic corner of J, dear to those who use it, but not something > we want a naive user stumbling across when they look up Forks. > > Henry Rich > > On 12/20/2021 9:14 PM, 'Pascal Jasmin' via Programming wrote: > >> modifier forks are parsed differently than traditional forks. > Modifer forks longer than 3 times are 3-grouped/parenthesised from left to > right instead of right to left of traditional forks. A mixed fork is a > modifier fork > > The last sentence is not accurate. I've attempted to describe the rules > for a mixed (modifier and verb in one) fork/train at: > > > > https://code.jsoftware.com/wiki/Vocabulary/fork#Longer_forks.2Ftrains > > > > Not sure if it is complete or as descriptive as it should be. > > > > > > > > > > On Monday, December 20, 2021, 03:38:15 p.m. EST, 'Pascal Jasmin' via > Programming <[email protected]> wrote: > > > > > > > > > > > >> And presumably there's some use for having the ability to carry around > > a partially constructed fork. > > > > A likely bigger advantage than parentheses avoidance. > > > > for a tutorial, I should probably have included the bible on modifier > trains earlier on the thread: > https://code.jsoftware.com/wiki/Vocabulary/fork#invisiblemodifiers > > > > modifier forks are parsed differently than traditional forks. Modifer > forks longer than 3 times are 3-grouped/parenthesised from left to right > instead of right to left of traditional forks. A mixed fork is a modifier > fork > > > > (+/ % # @ @) > > > > (+/ % #) @ @ > > > > the most useful partially constructed fork (or any longer than 2 param > modifier) "constructor"/compound modifer is one that provides binding > flexibility. > > > > The "native" modifier trains are already pretty complete. They can be > categorized into more useful/less useful categories. The more useful: > > > > A V NB. allows compound adverb modifier to bind V if it returns a > conjunction. (or create hook) > > A V V NB. simple fork with 1 parameter. or ]:WU in your world. if VWU > wanted instead then ]:W~U > > [. V ]. NB. conjunction with center param fixed > > AAV NB. where AAV is (]: ]: V )then it is U (]: ]: V)W a ~ allows V (]: > (]:~) U) W > > > > > > The last 2 are conjunctions with either a center or outter tine fixed. > This is the same as my F0 F1 F2 adverbs when they are fixed. But F0 F1 F2 > are more flexible in that they allow hook formation or by passing the ars > of modifiers, for purposes of modifier train forming. F0 F1 F2 also allow > binding first choice of 2 out of 3 possible parameters. Conceptually, F0 > F1 F2 are used because of a specificaly desired first binding, and when > that natural choice is made (U F0), (W F1) or (V F2) then there is full > choice in binding one of the remaining 2 params. > > > > A final completing native adverb train completer is: > > > > (U(]:]:V)) NB. adverb where W is final parameter completing the adverb > range: AVV and AV~V > > > > These 3 are the same as F01 F02 and F=:F12. The advantage of the Fmn > variants is they allow binding either one of the first 2 UWVs it > "specializes" for, and the hook + modifier ars to create modifier trains. > > > > > > The less useful "native" modifer fork forming trains. > > > > CVV -> (uCv)VV NB. [:VV would allow uCv to be passed with user choice of > C. Still useful if C genuinely "wants to be" fixed. > > VVC -> mirror of above that could just be CV~V > > > > W 'C' aar F0 U reproduces the first one. or > > > > +/ -'@' aar F % F # NB. native with @ given requires ([. ([. @ ].) ].) > > > > +/ -@% # > > > > +/ -([. ([. @ ].) ].) % # NB. cool that this works. > > > > +/ -@% # > > > > The F0 F1 F2 F01 F02 F12 compound modifiers provide less typing and more > flexibility (`:6 is J superpower) than the native fork forming modifiers. > But, if you don't want to learn them then the native versions are self > documenting if you understand them. ie. named functions you are unfamiliar > with always means looking them up (and then understanding them) > > > > > > On Sunday, December 19, 2021, 10:16:13 p.m. EST, Raul Miller < > [email protected]> wrote: > > > > > > > > > > > > For most purposes, zero fork constructing words are necessary. And, > > > > UW2V=: {{)c > > {{)c > > v=. {{ > > 0!:0'u=.',m > > u > > }} > > u (0{::n)v (1{::n)v > > }}((5!:5<'u');5!:5<'v') > > }} > > > > should be adequate for most of the examples where a fork producing > > word is necessary. > > > > But, personally, I don't do these things because they are necessary. I > > do them for fun. > > > > $ ;UW2V , > > $ ; , > > > > Hopefully it's obvious that I could have gotten the same result with > > $ ; , > > $ ; , > > > > That said, note that if instead of the 9!:3]5 which I have in my > > profile.ijs, I used some other verb display form, that that result > > would display different: > > > > 9!:3]1 > > > > $ ; , > > +-----------+ > > |+-+-------+| > > ||3|+-+-+-+|| > > || ||$|;|,||| > > || |+-+-+-+|| > > |+-+-------+| > > +-----------+ > > 9!:3]4 > > > > $ ; , > > +- $ > > --+- ; > > +- , > > > > I would say "of course", but I don't know how a beginner would know > > about this mechanism if they were not treated to a suggestion to try > > it. > > > > Still, I am fond of > > 9!:3]5 > > > > Anyway, back to the topic... we can do: > > > > ex1=: ;UW2V , > > ex2=: ,(;UW2V) > > > > $ ex1 > > $ ; , > > $ ex2 > > $ ; , > > > > And presumably there's some use for having the ability to carry around > > a partially constructed fork. > > > > But is UW2V automatically superior to UWV1? (Defined earlier today: > > http://jsoftware.com/pipermail/programming/2021-December/059410.html#) > > > > ex3=: ; , UWV1 > > $ ex3 > > $ ; , > > > > The construction of ex2 and ex3 are only superficially similar, since > > ex2 needs a set of parenthesis. And, on these forums, elimination of > > parenthesis has often been declared to be a highly important issue. > > > > So... there's that... > > > > ------------------------------ > > > > Finally, I should correct a statement I had made previously: > > > > This was wrong: "If you use parentheses, U W UW2V V would be > > equivalent to V (U W UW2V)." > > > > This turns out to be false. In older versions of J (if an > > implementation of UW2V had been written in that style), this would > > have been equivalent to (U W) UW2V V. But in J903, (U W UW2V) is a > > conjunction, not an adverb. And, using that conjunction results in a > > syntax error. I haven't worked through the details yet, of why this > > happens. > > > > Thanks, > > > > > > -- > > Raul > > > > On Sun, Dec 19, 2021 at 9:37 PM 'Pascal Jasmin' via Programming > > > > <[email protected]> wrote: > >> I did look over your list of 18, and the 6 extra you have over my 12 (6 > + 6 swapped) is indeed 6 triple (3 + 3 swapped) adverbs > >> > >> > >> + F1 > >> > >> ((ti+) ti (''ti)) `: 6 > >> > >> '+ F1'swapC NB. basically returns: > >> > >> > >> ]. (+ F1) [. NB. C C C train that swaps arguments to middle > conjunction. > >> > >> W is +, and W1 is an expression that takes W as adverb/single parameter > to return a conjunction, and should "still count" as xW1y form. swapC is > just a 7th compound modifier that combined with the first 6 makes the 12 > combinations excluding triple adverbs > >> > >> +/ # 'F12'swapC % > >> > >> +/ % # > >> > >> The (F1 V) binding (A V) is close to your triple adverb versions. > Triple adverb form has even less binding options than the other 2. (only 1 > order instead of "4"). With only limitations and no benefits, I wouldn't > bother to create those forms. > >> > >> > >> > >> On Sunday, December 19, 2021, 08:14:07 p.m. EST, Raul Miller < > [email protected]> wrote: > >> > >> > >> > >> > >> > >> 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 > >> ---------------------------------------------------------------------- > >> 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 > > > -- > 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
