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
