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
