> 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, -- Raul On Mon, Oct 4, 2021 at 3:43 PM 'Pascal Jasmin' via Programming <[email protected]> wrote: > > Going to use reply to Pepe as a case for changing trains before its too late > (ie before they get used) > > > > hook=. `(`:6) NB. (Equivalently, hook=. ``:6) > > This is an excellent contribution that shows the CC hook (defined as > duplicate arguments: (u C1 v)(u C2 v) offers no benefits. > > The only imaginable cases so far is to produce a hook, or to return (u n) or > (v m) to caller context. > > the only possible use of u n over u y (which would occur without the CC) is > that it is possible to bind u or n partially in an expression, or if u n > returns a verb or modifier. There is no natural u which can legally do the > former. > > It is possible to create a conjunction that replaces ` such that will accept > nouns or verbs as its arguments and produce gerunds. Without full > definition, my version is: > > ti =: 2 : 0 > > if. -. u isgerundA do. u =. u ar end. > > if. -. v isgerundA do. v =. v ar end. > > u,v > > ) > > a different conjunction is possible/needed if it is to allow quoted modifiers > to have their atomic representation included. > > with h. =: ti`:6 > > with u ti n `:6 not legally capable of forming a verb or modifier, it is > still possible to create that functionality with u n producing a string, and > > h.(1 :) > > could then be used to turn that future string computation into an adverb. > > C C -> ((u C1 v)C2) > > has benefits compared to using workarounds... Benefits > no benefits. > > > In the case of A C -> adv: u A (C u) > > the only "mainstream" benefit is the ability to make a conjunction > "reflexive" (]: C) > > theoretical completeness aside, this is not a huge programming application, > though if you knew a different way to provide this in a quoteless manner, > that would be best to eliminate all benefits. > > Even if some possiblity is created, benefits are inferior compared to this AC > definition: > > A C -> u A (C v) > > similar to A C A of A C ]: > > The annoyance of A C A pattern is that (A A) C A must be explicit to have a > sane interpretation. More parentheses means more tedious annoyances in > writting code, and avoiding tedious annoyances is a benefit. > > My total vision for the trains is that it is higher value to have auto > "pairing"/parenthesizing of "free" u and v's near Cs, than the general > minimal benefits that exist from the trains, although I will also support the > explicit triple parenthesing of as one example (V V C) as superceding the > auto-pairing rules. > > But forcing AA...A trains to now be parenthesized sometimes is a major > tedium downgrade compared to previous versions of J. > > So, for sure I will always hate AC and CC if they persist past beta. > > Reflexive conjunctions don't have the same mathematical symmetry of applying > well understood model/concepts of doubling, squaring, 0 and 1 which are so > well understood that they have their own primitives instead of using > reflexive forms. If you know you want a reflexive conjunction application, > then you can be forced into the tedious repetition of uACu or uCu. > > Even though each potential implementation of AC creates tedium in some > applications, it is far more tedious to parenthesize many future AA trains > then to provide duplicate conjunction parameters which no built in > conjunctions have any meaningful conceptual frameworks for. Exception > example: > > quadruple =: +:(]:@) NB. requires 2 more "shifted upper row" typing > characters than +:@+. Reading requires looking up the never used (]:C) > pattern. > > > > > > > > > > > > On Saturday, October 2, 2021, 07:51:20 p.m. EDT, Jose Mario Quintana > <[email protected]> wrote: > > > > > > > 1. it breaks existing valid code. > > Certainly, I had to repair my hg adverb in a couple of places (see below) > > > Alternative of (C0 V1) C2 turns this into A C train which has useful > interpretation. Avoids parentheses in > > I am fond of the C0 A1 bident and to a lesser extent of the A0 C1 A2 > trident. I like to write a pseudo while conjunction as, > > w=. ^:(^:_) NB. (Equivalently, using a resurrected trident, w=. ^:^:_ ) > > u w v > |value error > | u w v > > Darn! This new annoying feature that now triggers errors related to > m,n,u,v,x, and y even outside the scope of explicit forms is interfering. > Trying again, > > alpha w beta > alpha^:beta^:_ > > However, the main reason I like it is that the production of tacit > conjunctions can be reduced to the production of related adverbs; for > example, the conjunction (hook) to produce a hook can be written as, > > hook=. `(`:6) NB. (Equivalently, hook=. ``:6) > > alpha hook beta > alpha beta > > Alternatively, after scripting a repaired hg adverb script (that is, by > replacing the corresponding lines by > > d=. (a3=. (@: (aw f.)) ('av'f.)) (a4=. "62) (a5=. `:6) > > and > > hg=. (`((ar'a6')`(ar'a5'))) (`:6) > > ), > > hook=. ]hg > > alpha hook beta > alpha beta > > Moreover, using a suitable tacit verb instead of ] one can produce any > arbitrary form that is a function of its arguments with one caveat: noun > arguments would have to be boxed. This brings me to the A0 C1 A2 trident. > > This trident can be used to operate on raw noun arguments. One can define > first a noun boxing adverb, > > box=. ((<,'<') ; ])hg > assert (<1 2 3) -: 1 2 3 box > > (Incidentally, I realize I am using a shotgun to kill a fly, I know I can > easily use a pistol instead but I wonder what would be a gentle and kind > method to kill this fly (that is, to produce a nicer equivalent adverb to > the box adverb) using the resurrected trains or your alternative versions.) > > Then one can operate on noun arguments; for instance, > > 1 2 3 ((box ` box)(] hg)) (u0`u1`u2) > ┌─────┬──────────┐ > │1 2 3│┌──┬──┬──┐│ > │ ││u0│u1│u2││ > │ │└──┴──┴──┘│ > └─────┴──────────┘ > > Again, replacing ] above by a suitable verb one can produce, in principle, > any arbitrary form (that is a function of its arguments); for example, the > conjunction (linear) which produces the corresponding linear combination of > a list of verbs represented by the gerund can be produced as follows, > > 9!:14'' NB. By the way... > j903/j64/windows/beta-r/commercial/ > www.jsoftware.com/2021-09-26T14:46:15/clang-12-0-0/SLEEF=1 > > e=. &.> > x=. @:[ > y=. @:] > > left=. ('';1;0)&{:: > right=. ('';1;1)&{:: > plus=. ([ , (<,'+') , ]) > times=. < o ([ , (<,'*') , ]) > > linear=. (box`box)((an e o left > o ((plus e/) . (times e)) <e o right) > hg) > linear=. 'linear'f. > > 0 1 2 linear (u0`u1`u2) > (00 * u0) + (01 * u1) + 2 * u2 > 1 0j2 3j3 linear (^.`(% + ^)`(1 + *:)) > (1j0 * ^.) + (0j2 * % + ^) + 3j3 * 1 + *: > > (The linear conjunction is not only tacit (and fixed), > > _66 [\ (5!:5)@:<'linear' > (((("62)((`'') (&(((<,'<') ; ])@:(<@:((0;1;0)&({::)))@:[)) ((`(<(, > '0');_))(`:6))))(`:6)) ` ((("62)((`'') (&(((<,'<') ; ])@:(<@:((0;1 > ;0)&({::)))@:[)) ((`(<(,'0');_))(`:6))))(`:6)))((("62)((`'') (&((< > @:((,'0') ,&:< ])&.>@:(('';1;0)&({::)) >@:(([ , (<,'+') , ])&.>/ . > (<@:([ , (<,'*') , ])&.>)) <&.>@:(('';1;1)&({::)))@:(<@:((0;1;0)&( > {::)))@:[)) ((`(<(,'0');_))(`:6))))(`:6)) > > but it was produced tacitly, which is the only acceptable way from the > perspective of a genuine tacit fan(atic). ;) ) > > I am curious, again, to see how old-timers or newcomers can employ the > resurrected bidents and tridents (or your alternative versions) to > facilitate simpler equivalent versions of the linear conjunction shown > above. > > P.S. I do know how to produce a conceptually simpler, at least in my mind, > version of the linear conjunction (if necessary, as a curried adverb which > effectively takes a couple of arguments (aka, double adverb); for instance > when using a j807 interpreter) the wicked way. That is by casting > blasphemous spells which compel tacit verbs to produce also verbs, adverbs, > and conjunctions; just as adverbs and conjunctions do. In fact, I wrote > the linear conjunction first the wicked way and use it as a model for > writing the orthodox version (shown above) afterward. > > 9!:14'' > j807/j64nonavx/windows/release/commercial/ > www.jsoftware.com/2018-10-05T10:48:34 > > NB. After scripting the wicked tacit toolkit... > > plus=. [: [ +cv ] Train > times=. [: [ *cv ] Train > > linear=. > o (an e x ((plus e/) . (times e)) < o train "0 y) f.s2c > > 0 1 2 (u0`u1`u2) linear > (0 * u0) + (1 * u1) + 2 * u2 > > 1 0j2 3j3 (^.`(% + ^)`(1 + *:)) linear > (1 * ^.) + (0j2 * % + ^) + 3j3 * 1 + *: > > > > ---------------------------------------------------------------------------------- > > > On Mon, Sep 27, 2021 at 8:26 PM 'Pascal Jasmin' via Programming < > [email protected]> wrote: > > > > Lets start with the 2 worst, irredeemable most useless, trains > > > > C0 V1 C2 -> (u C0 v) V1 (u C2 v) fork result. duplicating input to both > edge conjunctions. Will never be used. > > > > Alternative of (C0 V1) C2 turns this into A C train which has useful > interpretation. Avoids parentheses in one of the 2 natural (validating) > parenthesizings of this string. > > > > C1 A2 -> u C1 (u A2) . A far less dumb alternative would be u C1 (v > A2). At least both AC and CA would be conjunctions. > > > > I prefer (u C1 v) A2 out of consistency and coherence. While u C1 (v A2) > may have a use, its 50/50 which would be used/wanted more. > > > > > > The next category is that of slightly longer combinations of A and C > > (the words coherent and consistent refer to qualities that let you > understand a concept/execution train instead of memorizing incoherent and > inconsistent result tables. A highly valuable, if not priceless, aspect of > a language.) > > > > AAC not defined. bad syntax error. (AA)C is fine interpretation and > already defined sanely. AA -> (AA) is everywhere else in J. > > ACA -> (u A) C (v A). Not useless, but not obviously more frequently > wanted than coherent ((u A) C v) A2 > > CAA -> coherent > > CAC -> doesn't exist. syntax error. Can be ((u C v) A) C2. An adverb > (or CA) result. > > ACC -> (u A) C1 (u C2 v) reuses u, making it useless. A perfectly > coherent result would be one equivalent to both (AC)C and A(CC). > Associativity is prizeable. > > CCA -> (u C1 v) C (u A). same uselessness. (CC)A or C(CA) preferably > identical interpretations is obviously better. > > CC not defined. Most important of all. -> ((u C1 v) C2) is an adverb. > The consistency with AC is that arguments are inserted with their natural > parenthesized order, and then consistent with V0 V1 C2 -> (V1 C2 V0) which > allows using conjunctions in strand/double adverb mode, which avoids the > frequent error of wishing the v argument to a conjunction referred to the > full verb phrase on the right. > > > > First, it is more useful that definitions exist than not. > > Two, definitions that reuse arguments for different modifiers have no > applicable use expectation. > > > > Its one thing to defend the interpretations that are not useless, over a > more consistent approach. I could listen to such a defense. It's an other > to defend useless interpretations. > > > > The next/last category are the ones that result in trains. Rather than > itemize each train, let me just go over one cool example that I can think > of. > > > > (] #~ ") > > 1 (= 2&|)(] #~ ")_1 i.5 > > > > 1 3 > > > > its cool, except that for the " conjunction, the correct right argument > is always _1 . But there is a cooler adverb form: > > > > (("_1) # ]) > > > > Noting that it's cool, might lose track that the purpose of the coolness > is that it can be assigned as an adverb. The power of J is in its higher > order functions that can be assigned. The alternative definition is: > > > > select =: 1 : 'u"_1 # ]' > > > > it is already very easy to make train results from adverbs. And an > enhancement: > > > > ns =: 2 : 'u"_1 v ]' > > > > allows substitutes for # as v. Including i. or perhaps a compound verb > that dug through a boxed structure inside items. A super cool conjunction > that was extremely easy to write (the important value provided), and even > cooler than the train version. Cooler means harder to name. > > > > The problem with inconsistent "non binding" of some arguments in modifier > trains is that I can write the following > > > > (] #~ " _1) NB. parses just fine. > > > > The intent is that if the rule of leftmost 3 parameters in a modifier > train get grouped together, and intent suggested by _1 indent, then perhaps > this means > > > > (] (#~) ")_1 NB. making an adverb out of original conjunction through > binding > > > > when it actually means: > > > > 1 (= 2&|)(] (#~ " _1)) i.5 > > > > 0 0 0 0 > > > > 1 0 0 0 > > > > 0 0 0 0 > > > > 1 1 1 0 > > > > 0 0 0 0 > > > > It is a minority of J users that understand trains. Adding conjunctions > and adverbs into permissible train formation items just adds an exponential > rate of errors, and removes accessiblity even further for most J users. > Sometimes the modifiers are binding, sometimes they generate a modifier > that results in a train... increases reading taxation, that requires good > memory of large inconsistent result tables, and whether a pattern fits into > one of the entries, and loses the mental simplicity of following a train's > dyadic/ambivalent terms to understand it. > > > > > > > If we change the old definitions that just means > > we have even more work to do. > > > > This can be done from the parsing table approach which may be manageable > > > > > SHORT examples > > > > +/ - @: -> +/ (-@:) -> -@:(+/) NB. gains strand notation for > conjunctions. Things consistently bind when you expect them to. > > > > + - * (@ @) -> + - (* @) @ -> + (*@-)@ -> *@-@+ NB. natural strand > binding order. Intuitively extendible to longer modifier train "saved name" > > > > If the A V -> V A proposal is accepted then, > > > > @ (+/) - -> -@(+/) NB. double left arguments also parse. This adds > flexibility to C C train for binding order: > > > > * (@ @)- + -> * (@-)(@+) -> *@-@+ NB. same end result but with more > partial binding options. Can be good simplicity argument for + - left > binding order for same result. > > > > Consistency with AC and CA means that binding any argument within the > conjunction train is easy > > > > (@@+) -> (@(@+)), (@-@) -> ((@-)@), (*@@) -> (*@)@ are all partial > bindings that allow same end result with further conjunction or strand > parameters... when AC and CA are consistent. > > > > > > part of the consistency importance is what happens when modifiers return > modifiers. Keep consuming right arguments is the "correct" behaviour. New > surprise incoherent trains are not welcome. > > > > > > > > On Monday, September 27, 2021, 01:15:18 p.m. EDT, Henry Rich < > [email protected]> wrote: > > > > > > > > > > > > The primary goal of reintroducing the old trains was to make the old > > documents valid. Whether there is a better way to define the old trains > > is not to the point. If we change the old definitions that just means > > we have even more work to do. > > > > You are not improving your credibility by asserting that 'all of the > > train results... are at best marginally useful'. I used them quite a > > bit and was sad to see them go. Indeed, I never had a case where I > > wanted to write a modifier and found the trains wanting. I admit that I > > was content with the structure of J as it is, not trying to create a > > different approach to function definition. > > > > You would have to actually demonstrate examples where an alternative > > definition would enable some important new application. Then we could > > judge whether the change is worth the large effort required. I would > > add, we would need to do this before the beta period expires. > > > > I have just now gone through some of your list of proposed changes and I > > have yet to find one I agree with, but that's just my opinion. The > > burden is on you to demonstrate the superiority of your proposal. Just > > one SHORT example would be a good start, something important that the > > old trains are lacking. With luck we might find that you are redefining > > something so obscure that no one has ever used it, for which a change > > would be easier. > > > > In the meantime, adding parentheses to your bidents is harmless and > > solves your problem. > > > > It is gratifying to see the interest that this old code has ignited. > > > > Henry Rich > > > > On 9/27/2021 12:46 PM, 'Pascal Jasmin' via Programming wrote: > > >> Since you can > > > easily make your old code work by putting parentheses in +@/ to make > > > (+@)/ and that preserves old documents, that would be the best solution. > > > > > > That J sometimes "does what I mean" is a mixed blessing. Great when it > works, but relying on it means syntax errors due to its incompleteness in > applying the intuitive concepts that could make writing modifiers easier. > > > > > > It all boils down to "could Ken have made a mistake" > > > > > > Modifier trains are an awesome idea, and it is great to have enhanced > interpretations of code. > > > > > > Removing these interpretations for J6 were viewed as a better idea than > these interpretations. > > > > > > The appeal of modifiers trains that return trains can seem less scary > than modifiers that return modifiers. The latter though is part of the > language since at least J6. Some of the "old trains" do the sane modifier > autobinding, while others return trains. > > > > > > All of the train results, if not completely useless, are at best > marginally useful. A good test would be for someone to come up with a > single useful function in that form. Even if such a function exists, it > can be easily/clearly written as a custom modifier in less time than it > takes to research whether one of the train producing modifier trains > provides a useful equivalent shortcut. > > > > > > CC CA AC CnvC provide tremendous benefit in having valid > interpretations. Who wouldn't prefer more valid parsings and less syntax > errors. But the benefit only exists when interpretations are coherent, > useful, and consistent. That benefit only occurs if all of the modifier > trains produce the natural modifier bindings that a fully bound in place > expression would produce. > > > > > > > > > That it might be scary to consider CC an adverb that produces a > conjunction (u C1)C2 -> AC -> (uA)(Cv) or a conjunction that provides an > adverb ((u C1 v)C2) doesn't force you to use the scariness. It is > consistent with the C C V train, and almost the V C C train. (the > execution of v1 C v2 C V is (v1 C v2) C V, while V C C produces V C (v2 C > v3)). While V C C can have useful applications, the "special" bracketing > can be accomplished if CA had a sane interpretation (u C v)A. Then V C1 C2 > to have current interpretation can be written as C2 (V C1). > > > > > > To Ken's credit, the dumb C A train can be avoided with C A 1 : 'u'. > ie C A A is sane. > > > > > > C V C (and all duplicate u/v modifier trains) however are just mistakes > and useless. > > > > > > Reintroducing these trains has great potential. But we need to fix the > bad ones before code gets written using them, and irreparably breaks J's > potential. > > > > > > It can also break complex embedded existing code. Techniques for > strand/double adverb notation might rely on interpreter quirk, though are > no longer needed with my proposal. > > > > ---------------------------------------------------------------------- > 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
