Thank you Henry,
One way to make it more J like, and increase functionality would be a gerund right argument. The
gerund can be complicated to construct for user because parameters can include nouns or
"embedded" gerunds, but the functional advantage is being able to bind the outter left
(u2) argument But that means (u2 `)C C has to have "meaning" of
AC-> uA(Cv) has great symettry benefits with CA, and code readability.
as to the specific ugliness of
5 + - (C0 C1) * 6
display could show
+ (- (C0 C1) *) NB. good readability aid for all modifiers that return
modifiers: Extra parens in display around bound modifier.
But there are already several new readability challenges included in beta-r
2 (1 = |)(]: # ]) i.5 NB. includes eyesight/dyslexia challenges for ]: vs [:
As for name readability, some of my other proposals help. Parsing rules:
Any C v -> Any (C v) NB. u(Cv) is more readable than uCv display when named
conj: u named v vs. u (named v). C only option for named
C u C -> (C u) C
notC u C -> notC (u C)
This would break C V V, V V C and explicitly C V C. The latter has no value, and
the former 2 are marginal train formation utilities that have easy alternatives.
C V V would turn into (C V) V, and V V C into V (V C) (executed) . This supports
the rule for A V -> (V A) to allow binding of parameters in any direction.
CVV VVC and more worthy uCA uCC and ACA can all supercede (as triples, and CVV,
VVC only when explicitly parenthesized) the above parsing rules. But changing
AC also allows
AAC -> (AA)C
CAA -> C(AA)
This would restore current modifier train behaviour that does not require an
extra level of explicit parens around AAA...A trains.
CAC -> (CA)C = CC train is possible, though forcing parentheses choice on
writer is very reasonable too.
CCC -> (CC)C = CC means (C1 C2) (C3 v1) = CA -> C1 (C2 v2) (C3 v1) = C(AA) -> (u1
C1) (C2 v2) (C3 v1) = (AAA) = A -> u2 (u1 C1) (C2 v2) (C3 v1)
A useful alternate for CCC would still require 4 parameters -> (u1 C1 v2) C2
(u2 C3 v1) . This may be ok as (CC)C or C(CC) can be explicitly written to escape
CCC interpretation.
whenever AC CA or CC occur, double space would separate them in display and
encouraged writing style. Perhaps CC gets triple space.
named modifiers have always presented readability challenges. I prefer G0 to 0 G for G =:
(&{::)@] because of the fork readability issue of spaces separating verb phrases. A
readability aid could be a non executable UTF symbol(s) that can either be input or added
display. These could flag a name as a adv/conj (each own UTF superscript), or replace space
as binding of parameter (ie. for non alpha-named modifiers convention is to put no spaces
between bindings) or display-separator of train tines. bound Modifiers that are modifiers
can in addition to parens get a UTF superscript mark too. These marks could be added in JQT
on file load/save, but would not be part of the save file. There would need to be a
"strip/add function" such that ;: or clipboard can get decorated/undecorated
HR: not mentioned yet in favor of modifier trains, namely
that they execute in the user's namespace rather than in the namespace
of the modifier. As an aside, the User is here looking to execute
monadic verbs,
2 : 'u v' also executes in user's name space. I call semi-tacit modifiers those that do
not access x, y or names in an implied locale. Named u v parameters will be passed back
"unexecuted"
HR and RH: Just define it as 1 : 'V m'
You may mean 2 : 'v m' as one of the conjunctions in CC? I think that still forces one
of the conjunctions to sensibly be ]. or [. and then this is just CA or AC disguised, and
really just a single C. If instead it means that one of the conjunctions returns a
modifier, but only needs one input parameter (u or v). Let's call these "fake
Adverbs". Instead of only returning ([. ].) hook, with fake adverbs you may do with
CC (u FA) (v FA) where (v FA) returns a modifier that will get applied to u FA result.
But this is a convoluted use of CC that can easily and more simply be
implemented by instead of defining/using 2 fake adverbs, a single conjunction.
If both fake adverbs return modifiers, then you get the readability challenges
you wanted to avoid with all of the duplicate input trains, that require FAs
for sensible use/trickery.
HR: But if I use an explicit form for A, such as
you give above, local variables referred to in m.
are not accessible inside A .
if an A/FA returns the adverb 1 : (u lrA , ' m') then any named u is in caller context, and future
m will get processed in caller context. The context problems occur in a "real
conjunction" where you might try to execute v m, instead of returning the "future
modifier". I may not have understood your points here.
On Tuesday, September 28, 2021, 10:03:25 p.m. EDT, Henry Rich
<[email protected]> wrote:
One of our points of disagreement is this:
PJ: You know what's better than modifier trains with a limit of 2
floating parameters? 3 or more.
I don't agree. To me it's abominable. It reminds me of when I was
learning Latin: I don't see where the verb is. Consider your proposed
production
(C0 C1) -> conj ((u C0 v) C1)
What would this look like in use? It takes 2 operands and produces an
adverb (usually), so it would require another operand before it could
take noun arguments. A minimal invocation would look like
5 + - (C0 C1) * 6
[To get the full effect, imagine that there are names for C0 and C1, and
it's not obvious that they are conjunctions.] To me, this is
un-J-like. It's an inside joke, not a language for expressing ideas
clearly.
Now, that's just my opinion. I am willing to accept being outvoted.
But you would have to convince a great many users that this is the way
the want their J programs to look. Good luck. If you are voted down
you can still express your ideas with explicit modifiers.
MEANWHILE, Brian Schott has pointed me to a thread from 20 years ago,
when a Wise User was advocating for (C0 C1) -> ((u C0 v) (u C1 v)). The
User makes a point not mentioned yet in favor of modifier trains, namely
that they execute in the user's namespace rather than in the namespace
of the modifier. As an aside, the User is here looking to execute
monadic verbs, a 'reasonable application' not envisioned by PJ:
Roger said:
Just define it as 1 : 'V m'
The Wise User replied:
That doesn't do in the application I am working on.
m is a string, which V parses to find variable names;
it evaluates the variables, crunches a bit, and produces
its result (which is an atomic representation which
I then convert to a verb - that's why it has to be
an adverb that produces the noun).
But if I use an explicit form for A, such as
you give above, local variables referred to in m.
are not accessible inside A . If I use the ugly tacit
form of A, it can access all the variables that are
in scope when A is invoked.
I think the User's points are sound. But then I would, wouldn't I?
Henry Rich
On 9/28/2021 7:30 PM, 'Pascal Jasmin' via Programming wrote:
the case for CC -> (u C0 v) C1 : adverb result which will end with u C0 v C1 u2
after u2 gets passed is:
as a starting point, we have to look at how bad your proposal is.
The only reasonable application is creating the hook ([. ].) due to the
duplicate binding. Theoretically, there could be separate conjunctions that
have switch/case tables that use u v as codes for what to emit, or conjunctions
that read some global state to produce emissions, but such sillyness should be
the domain of verbs, or at least a single conjunction that does something so
sophisticated.
H =: 2 : 'u v'
provides an easier to type shortcut for the only application compared to ([.
].) or {{u v }}. The latter is faster to type out of the 2. A great power of
J is the power to create anonymous functions simply that provide direct context
instead of a name. So {{u v}} might be preferred to H_z_ if you don't use H
enough to know what it is.
To address Raul's good post about how easy hooks and trains are to produce with
modifiers
My core problem with the old trains is that they are focused on making easy
train formation a tiny bit easier at the expense of confusion, while ignoring
the relatively tedious aspect of processing modifiers (need to be quoted) and
enhancing adverb/modifier trains
I'll repost a link to my templating system
http://www.jsoftware.com/pipermail/programming/2020-September/056558.html
and add an extra definition that leverages the templating system (missing
aatrain definition provided if any interest) for a fork
F =: ((jt '4: 3: 2:') Jxp aatrain.
which returns adverbs until the template is full (3 terms provided)
+ - * F NB. returns fork of items in order.
+ - *
* + - 9: F NB. 9: replaces low number template item with high template
item... defers first binding to last
+ - *
- + 'u' * F NB. same but will generate a final adverb
+ - *
'v `u ` *' bb F NB. bb cuts on ` can be used to return conjunction that
will fill train.
2 : 'v u *'
- '+ ` ` *' bb F NB. empty box alternative to deferring binding
+ - *
'+ ` @ ` *' bb F NB. useable to build bound conjunctions as well.
+@*
1 = 2 | ] F F (#~ H) i.5 NB. F F will make 5 length train. All of the
parameters could be deferred. (#~ H) adds select hook
1 3
The point being that building trains from modifiers where parameters can be provided in
any order, and any "prebound state" is a solved problem. Hooks are especially
easy with a conjunction, and wasting CC on having a single application of making a hook
conjunction is wasting the most powerful modifier train component.
The other point is that if you want to create trains with modifiers (what old
stuff does), you want to create modifiers, and the more you have, the more you
will want to combine them. Being able to combine them elegantly with a minimum
of parentheses is a benefit to having a large arsenal of modifiers.
I started my original rant, before I knew there were [. ]. ]:, and I have since
found workarounds for my gripes.
modifier trains are awesome, but were limited to one floating parameter.
CA train is perfect. Now opens up having 2 parameters in modifier train, as
long as C heads it.
the ACA train allows for a sane AC (C ending modifier train) interpretation
with a ]: as A2. It also allows the C to be in the middle, and if you prefer
uA(Cv)A to uA(C(vA)) then its just ]: tricks
+ ((/\) (@ /) (@])) =
+/\@(=@])/
+ (]: (@ ]:) /\) =
+@(=/)\
+ (]: (@ ]:) (/\)) =
+@(=/\)
extra parentheses burden over single modifiers, but its possible to write any
modifier train with 2 floating bindings (ie conj)! Hooray, Ken's brilliance is
restored :)
You know what's better than modifier trains with a limit of 2 floating
parameters? 3 or more.
The recommended C C train would allow that 3rd parameter, but it can get messy
with (C C) C.
On Tuesday, September 28, 2021, 02:33:17 p.m. EDT, Henry Rich
<[email protected]> wrote:
The argument for (C0 C1) -> conj (u C0 v) (u C1 v) looks pretty strong
to me, especially as it allows modifier trains to use special code in
hooks. And, it's backward compatible. I will implement that unless
someone can see a reason not to.
I see no equally-good way to create a verb fork with 3 input verbs. It
is possible to create conjunctions that consume operands and return a
modifier, thus allowing more than 2 operands in the final result; but
the resulting code doesn't look like J at all. We will need a lot more
thought and consensus before we go down that path.
Henry Rich
