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

Reply via email to