longer arbitrary chains of ACCAACVC trains are not possible within a coherent mental model because some combinations are undefined, and others reuse arguments in separate modifiers such that no coherent usefulness can be implied.
On Monday, September 27, 2021, 10:17:16 p.m. EDT, Henry Rich <[email protected]> wrote: Scanning your message, I don't see any examples of things that can't be done with Ken's language. I conclude that you don't have any such examples. Henry Rich On 9/27/2021 10:06 PM, 'Pascal Jasmin' via Programming wrote: > 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 -- 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
