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
