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
