I would be tempted to use "systematic pattern" over "invisible modifiers".
That said, borrowing from grammatical terms might be a better option. Though I am not sure how good of a fit "absolute phrase" would be here -- https://www.dailywritingtips.com/7-classes-of-phrases/ I hope this helps, -- Raul On Tue, Dec 21, 2021 at 6:59 PM Henry Rich <[email protected]> wrote: > > I moved Pascal's new stuff to an Ancillary Page. I am OK if someone > wants to move the Invisible Modifiers to a new page too. > > You can't give them a Rankbar, because they don't have a part of speech, > never mind a rank. > > And I say they have no Common Uses. They are too esoteric. The only > Introduction is 'here's the language, good luck with it'. > > Really, the babytalk that is NuVoc's style just doesn't work for these > features. > > You got a problem with "Invisible Modifiers"? Find a better term. What > we have here is a language with no syntax except for (), with all the > meaning given by the parts of speech of the words involved. I chose > "Invisible Modifier" to emphasize that the humble hook and fork are > compounds like u@v, but with no symbol used for the connective. > > Henry Rich > > On 12/21/2021 9:10 AM, Ian Clark wrote: > > 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 > > > -- > 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
