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

Reply via email to