All I would be interested in reading is a SHORT example of something that can't be done without changing the language. We are NOT trying to find the best design.
Henry Rich On Mon, Sep 27, 2021, 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. > > > > + 1 : '@u/' > > > > (@+)/ > > > > On Monday, September 27, 2021, 09:58:26 a.m. EDT, Henry Rich < > [email protected]> wrote: > > > > > > > > > > > > The original parsing rules proved very useful. As you point out, > > reinstating them does change the meaning of some trains. 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. > > > > If it would help you find what needs changing, I could type out a > > message when a modifier trident is parsed. > > > > Henry Rich > > > > On 9/27/2021 9:28 AM, 'Pascal Jasmin' via Programming wrote: > >> beta-r breaks the partial sane autoparenthesizing that existed for > short expressions > >> > >> in 9.02 > >> > >> +@/ > >> > >> (+@)/ > >> > >> @+/ > >> > >> (@+)/ > >> > >> > >> it "breaks" when it gets too long > >> > >> @+@- > >> |syntax error > >> > >> But usually/always the intent when you write the above is (@+)(@-). > The syntax error is at least helpful that the parser is just incomplete in > being able to handle longer versions of its short parsing talent. > >> > >> with beta-r, your breaking valid sane code no one ever called a bug, > and replacing helpful syntax error with "mostly garbage" functional > interpretation > >> > >> Mostly garbage could be considered complete garbage. The case for > "mostly" is that some of the trains do the sane thing they should > >> > >> *(+@-@) > >> +@-@* NB. exactly sane result of autoparens. > >> > >> *(@-@+) > >> > >> *@+ - *@+ NB. complete useless garbage when you might have intended a > sane use but got the train rules mixed up, and in this case the parsing > greediness determines the sanity/insanity. (long trains group the leftmost > 3 terms) > >> > >> +@-@ is adverb (+@-)@ = sane > >> > >> @-@+ is (C V) ((@-@)+) where the conjunction part is a fork that is > useless because of duplicate arguments to the (C0 V1 C2) train. > >> > >> > >> beta-r is harmful because: > >> > >> 1. it breaks existing valid code. > >> 2. produces worse expressions than a syntax error. > >> 3. prevents the natural and useful enhancement of J's parsing by > interpreting garbage of no practical use. > >> 4. Modifier trains are an extremely useful addition to J, but only if > they have useful interpretations. > >> > >> (C V C) conj -> (u C V C v) ie. interpreted the same way as if terms > had been written inline is intuitive and powerful partial function > enhancement > >> > >> . > >> > >> On Monday, September 27, 2021, 02:29:30 a.m. EDT, Raul Miller < > [email protected]> wrote: > >> > >> > >> > >> > >> > >> Parenthesization is basically talking about how the parser itself > >> functions. Every point where the parser combines tokens is a point > >> where you could place a parenthesis pair in the original text without > >> significantly altering the parsed meaning of that text. > >> > >> So proposals involving changing the parenthesis rules are proposals to > >> replace the parser itself. > >> > >> But changing the parser would invalidate quite a bit of existing > >> documentation on J, which would place a severe burden on the J > >> community. > >> > >> Take care, > >> > >> > >> -- > >> Raul > >> > >> On Mon, Sep 27, 2021 at 12:42 AM 'Pascal Jasmin' via Programming > >> <[email protected]> wrote: > >>>> When you envision 'even longer modifier trains', you are implicitly > >>> requiring a stack of more than 4 words. > >>> > >>> which can be avoided by (auto)parenthesizing outer modifier train, > such that there's always at most 4 tokens. > >>> > >>> > >>> Do I understand the following expression to mean that modifier trains > group left to right (somehow)? > >>> > >>> @ @ + - @ > >>> > >>> (@ @ +) - @ > >>> > >>> > >>> @ @ + - @ / > >>> > >>> ((@ @ +) - @)/ > >>> > >>> > >>> > >>> / @ @ + - @ > >>> > >>> |syntax error > >>> > >>> | /@@ +-@ > >>> > >>> > >>> / (@ @ + - @) > >>> > >>> /((@ @ +) - @) > >>> > >>> > >>> @ + @ - @ > >>> > >>> (@ + @) - @ > >>> > >>> shouldn't it group from the right? > >>> > >>> > >>> On Sunday, September 26, 2021, 10:46:13 p.m. EDT, Henry Rich < > [email protected]> wrote: > >>> > >>> > >>> > >>> > >>> > >>> Since the goal was to make the old documents still usable, changes > would > >>> require strong arguments demonstrating their superiority. You are > >>> pitting yourself against Ken Iverson: may the better man win. > >>> > >>> I can assure you that whatever is in your 'templating system' had zero > >>> influence on the design and implementation of {{ }} . > >>> > >>> When you envision 'even longer modifier trains', you are implicitly > >>> requiring a stack of more than 4 words. > >>> > >>> Henry Rich > >>> > >>> On 9/26/2021 10:34 PM, 'Pascal Jasmin' via Programming wrote: > >>>> I've been working on an autoparenthesizing of modifier trains, with > interpretations that would seem much more useful than the "old stuff". I > don't have a good interpretation for A V train, so I guess it could stay as > suggested. The following are what I'd prefer, added after -> ( = means > equivalent) > >>>> > >>>> > >>>> V0 V1 C2 conj V0 V1 (u C2 v) -> V0 (V1 C2) = V1 C2 V0 > >>>> A0 V1 V2 adv (u A0) V1 V2 > >>>> C0 V1 V2 conj (u C0 v) V1 V2 -> (C0 V1) V2 = A V2 > >>>> C0 V1 C2 conj (u C0 v) V1 (u C2 v) -> u (C0 V1) (C2 v) > >>>> A0 A1 V2 conj (u A0) (v A1) V2 -> (u A1 A2) V2 > >>>> N0 C1 A2 adv N0 C1 (u A2) -> u (N0 C1) A2 > >>>> N0 C1 C2 conj N0 C1 (u C2 v) -> u (N0 C1) (C2 v) = ((N0 C1 u) > C2 v) = (v (u (N0 C1)) C2) parentheses not needed. > >>>> V0 C1 A2 adv V0 C1 (u A2) -> u (V0 C1) A2 > >>>> V0 C1 C2 conj V0 C1 (u C2 v) -> same as N C C > >>>> A0 C1 N2 adv (u A0) C1 N2 > >>>> A0 C1 V2 adv (u A0) C1 V2 > >>>> A0 C1 A2 conj (u A0) C1 (v A2) -> u A0 (C1 v) A2 > >>>> A0 C1 C2 conj (u A0) C1 (u C2 v) -> ((u (A0) (C1 v)) C2) = > adverb > >>>> C0 C1 N2 conj (u C0 v) C1 N2 -> v (u C0)(C1 N2) = (u C0 v)(C1 > N2) > >>>> C0 C1 V2 conj (u C0 v) C1 V2 -> same as above > >>>> C0 C1 A2 conj (u C0 v) C1 (v A2) -> ((u C0 v) C1) A2 = adverb > >>>> C0 C1 C2 conj (u C0 v) C1 (u C2 v) -> ((u C0 v) C1) C2 = > conjunction A C > >>>> A0 C1 adv (u A0) C1 u (adverbial hook) -> (u A0) C1 v > >>>> > >>>> The beauty of the suggested forms is that there is not much to > remember, and allows for parenthesless forms. > >>>> > >>>> V0 V1 C2 -> V0 (V1 C2) is just the only valid parenthesization of the > left expression. > >>>> > >>>> C0 vn C2... More modifiers -> (C0 vn) C2...M ie. when a nv term is > between 2 conjunctions it binds to the left one. > >>>> > >>>> Whenever C vn appears, (C vn) is bound is the only special rule. It > binds ahead of other modifiers to right. > >>>> > >>>> To permit even longer modifier trains, while keeping the 4 token > stack: > >>>> > >>>> C0 C1 M2 M3 -> C0 C1 (M2 M3) > >>>> > >>>> Reusing parameters in multiple modifiers seems stranger than the > still strange inserting them seemingly arbitrarily within a modifier train. > If these are useful, they are best made into a purpose modifier rather than > as default parsing rules that will confuse. > >>>> > >>>> A cool enhancement would be multiple right bindings to modifier > trains that contain multiple conjunctions: > >>>> > >>>> (C0 C1 M) v -> (C0 v) C1 M ie. A conjunction modifier train binds v > to the leftmost (unbound) conjunction. > >>>> ((C0 v) C1 M) v2 -> (C0 v) (C1 v2) M = (C0 C1 M) v v2 > >>>> u ((C0 v) C1 M) -> ((u C0 v) C1) M ie binding from left or right > provides options similar to "old stuff" > >>>> > >>>> templating system that may have formed basis for {{ }}, and allows > for rich custome modifier trains: > http://www.jsoftware.com/pipermail/programming/2020-September/056558.html > >>>> > >>>> > >>>> On Sunday, September 26, 2021, 12:01:45 p.m. EDT, Henry Rich < > [email protected]> wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Nostalgic old-timers will be happy to see the return of Modifier > Trains, > >>>> such as (@/), which were in early J but were deleted long ago. See > >>>> https://code.jsoftware.com/wiki/Vocabulary/fork#invisiblemodifiers . > >>>> > >>>> These trains were one of Ken Iverson's elegant brilliancies. Few used > >>>> them, and they are not needed, because anything they do can also be > done > >>>> with explicit modifiers ({{ u @ v/ }} is equivalent to (@/)). No one > >>>> need rush out and look at them. > >>>> > >>>> We have brought them back because to do so was easier than updating > all > >>>> the old J literature that refers to the forms. And because they're > cool. > >>>> > >>>> Henry Rich > >>>> > >>> -- > >>> 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 > > > > > > > -- > 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
