a=:{{a
select. m
case. 0 do. 5
case. 1 do. /
case. 2 do. &
case. 3 do. +
case. 4 do. i.
end.
}}
3 a 1 a 4 a 0 a 2 a 3 a 0 a
45
On Mon, Sep 27, 2021 at 11:15 AM Henry Rich <henryhr...@gmail.com> 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 <
> henryhr...@gmail.com> 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 <
> rauldmil...@gmail.com> 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
> >> <programm...@jsoftware.com> 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 <
> henryhr...@gmail.com> 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 <
> henryhr...@gmail.com> 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
