> You got a problem with "Invisible Modifiers"? Find a better term
Modifer trains? I understand that NVV and VVV are included for completeness, but the list is mostly/focused about "parser trains" which nearly all (except for already known nVV VVV "traditional trains") form modifiers. I don't understand the invisible descriptor. I will update that other page tonight to be less muddled. I will copy the modifier train table to that page because a reference is needed for most any reader. On Tuesday, December 21, 2021, 06:59:36 p.m. EST, 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
