A better question is whether beta-r harms the language and how, which is why I started the reply with how it is harmful. beta-r locks us into some dumb choices, and the confusion resulting from inconsistencies, or just memory tax, will be a nightmare. Especially with 4+ long trains.
consistent AC CA CC CvnC modifier trains are extremely useful. It extends modifier trains to include conjunctions. These are the only new necessary trains, which would shorten the lookup/parsing tables. It allows for valid interpretations of: (+@@-/\) an adverb train with only one valid parentheses/interpretations. It cannot be written as fast without the language improvement. A few of us have found ways around the absence of conjunctions in modifiers. Its possible without language changes. beta-r would "force" support for some terrible train choices, or abandon something that was working well enough. On Monday, September 27, 2021, 08:45:08 p.m. EDT, Henry Rich <[email protected]> wrote: 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
