First of all, I have to thank David Lambert
for pointing out that I mistakingly wrote
nan SE
I should have listed it in the first section
NAN executed immediately (NA) N
(and I repeat VVN should have been “execute immediately”, too)
I try a more systematic approach
We had
NCN NCV VCN VCV
and
ACN ACV CCN CCV VCA VCC ACA
let’s complete those lists with current behavior of
NCA I say: keep N C uA
NCC N C uCv (add!)
(42/80)
the only C-forks remaining are
ACC CCA and CCC
I’d keep their interpretation open for now.
so the general rule would be:
in a fork around a C, fill in u and v to get a V/N C V/N fork:
• if the other ones don’t need any further arguments,
execute
• if the other ones together need at most two arguments,
they’ll take them (one: adverb; two: conjunction)
• three forms remain and may work differently
what about verbs?
we already have
NVN VVN VVV NVV
and
AVV VVC CVV CVC
and
NVC (add!)
was that “krof” concept a silly idea? I’m unsure
but let’s consider
AVN CVN
dealt with as well
actually, I like CVC to enable distributing u and v
but I don’t think that has much application so
we don’t need ACC CCA or CCC to distribute, too
what to do with trains ending with A? NVA VVA AVA CVA
one approach would be to always have the
VA execute first, and evaluate the remaining hook
but this needn’t be so
AVC I’d like this to be uA V vC
resulting in something like ?VA
(43/80) (3+4 open)
what about nouns?
We have
NNN NNV VNN ANN
and I wanted to supplement
CNN SE
(44/80) (3+4 open)
but I’m not as sure CNC should be a SE, too
one might want to have a trailing A take precedence
NNA VNA ANA CNA (open)
then a trailing C should take precedence as well
NNC VNC ANC (open)
how do we want the remaining
VNV ANV CNV
to behave? That is not at all obvious and may be used
to fill in productions that are otherwise hard to achieve;
or they may stay SE
still (44/80) (3+(4+4+3)+1+3 open)
And finally, adverbs:
We have
VAN VAA
NAN (works)
AAA NAA
Again, a trailing adverb could take precedence:
CAA stays uCv A A
But one could also decide on uC A vA
Actually, I don’t think AAN should be a SE anymore:
AAN should be either of (uAA)N or uA vA N
the latter would be in keeping with current
AAV
and I’m fine with that even though it is not
obvious (to me) that one would want it that way
(46/80) (3 + 3 + (4+4+3+1) open)
• if the train needs no arguments,
it’s a simple train or a SE
• if the train can take at most two arguments,
it just takes them, preserving their order
so we can also say
NAV shall be N uA V
VAV shall be V uA V
(48/80) (3+1+3+(4+4+3+1) open)
The remaining forms all contain a C:
NAC VAC AAC CAN CAV CAC
I personally would let a single C take precedence:
NAC N A uCv
VAC V A uCv
AAC A A uCv
CAN uCv A N
CAV uCv A v
then only CAC remains and may be used for
something missing from this modifier language
(53/80) (3+1+3+1+(4+4+3+1) open)
the seven remaining forms are the hooks
NN NV AV AA AC CA CC
(we had AN)
I’d say NN and NV should remain syntax errors,
and AA should work like this: uA vA
likewise, I’d have AV do uA V
AC CA and CC I’d say are open for discussion,
implement what’s missing from the modifier
language here
(57/80) (3+1+3+1+3+(4+4+3+1) open)
This is but a first shot at them, yet at least
it’s complete now, and I assembled a couple of
general rules along the way making them easier
to reason about (at least for me, that is)
Hauke
Am 30.09.21 um 15:45 schrieb Hauke Rehr:
Let me share some thoughts that came to my mind when
pondering over all those trains.
What do I mean by “all those”?
I’d like the list to be complete with (#'nvac') +/@:^ 2 3 combinations
I wouldn’t have done this because I thought back in the
days when J used to have these trains, they may already
have been optimized well and I understand very little
of them and have hardly any experience using them.
But now I take Henry’s call to the “interested parties”
as an invitation to tell you what I make of it.
First of all, we want most of the combinations that didn’t
result in a syntax error to keep doing what they used to do
(attempt of backwards compatibility with recent J versions)
So:
VN execute immediately
NA execute
VA execute
VV hook
NC adverb (curry)
VC adverb (curry)
CN adverb (curry)
CV adverb (curry)
NVN execute immediately
VVN V(VN)
VVV fork
NVV fork
VAN execute immediately (va) n
VAA execute
NCN execute
NCV execute
VCN execute
VCV execute
(18/80)
as we already have different interpretation
at least in one case, altering train semantics
is actually an option: NCA adv N C uA
example: (I’m bad at finding examples)
nca =: 5 2"/
(+ nca) 1 2 3
was: 5 2
5 2 (NCu)A
is: 5 2 NC(uA)
in this example, the former interpretation is intended
another example
nn =: -`^
nca =: nn @. /
minprty =: <.&(2&|)
(minprty nca) 7 3 1
was: 343 (NCu)A
is: 1096.63 20.0855 2.71828 NC(uA)
here both interpretations could have been intended
(I had to choose verbs that work in both cases
rather than verbs that make sense using this way)
-> restore oly behaviour or stick with the new one?
from a grammatical point of view, which one is the guiding principle:
trailing adverbs are executed last (parenthesize prefix) so -> (NCu)A
or
the middle C is fed the results of its neighbours just like in VVV;
N doesn’t need an argument but A does, so -> NC(uA)
personally, I like the latter better;
and one may still do (NC)A explicitly
(still 18/80)
Secondly, I’d want at least these to keep resulting in syntax errors (SE)
nnn SE
nnv SE
nan SE
vnn SE
ann SE
(23/80)
Then there are quite some forks I’d want to stay as they are:
AAA uAAA
NAA execute
AVV uA V V
ACN adv uA C N
ACV adv uA C V
CCN uCv C N
CCV uCv C V
VCA V C uA
VCC V C uCv
ACA conj uA C vA
VVC V V uCv
CVV uCv V V
CVC uCv V uCv
(36/80)
General ideas:
On the fork page, vvv and nvv share a row, and that’s for a good reason.
With modifier trains, v and n both play the role of x and y in verb trains.
I usually think of modifier trains as “not saturated” and in need of
getting complemented by n/v arguments.
So I’d propose joining all those pairs/quadruplets of rows,
e.g. ncn ncv vcv vcn,
and, for the sake of consistency, adding at least
AN adv uA N
NVC conj N V uCv
(38/80)
I’d like to generalize forks to include what may be called a krof,
a flipped fork
AVN krof: (N V~ uA)
CVN krof: (N V~ uCv)
or is this impossible because …VN <-> …(VN) always takes precedence?
(40/80)
Thinking about AC made me wonder:
don’t we need conjunction analogues to ~?
(one for reflexive, another for passive)
I stop here; there are too many forms amoung the missing half
I’m not done with finding out how I’d want them to behave.
Most likely, I’d want to add something like
NVA adv N V uA
NCC conj N C uCv
and have combinations like
aan
cnn
cnc
still result in a syntax error.
But there’s much I have to think through before.
And, maybe even more importantly, I should try
more examples with all the working forms.
Hauke
Am 29.09.21 um 18:39 schrieb Henry Rich:
These are good ideas, especially about bringing gerunds in, and I will
have to think about them. I encourage the other interested parties to
do so as well.
I may not get to it soon, though, because except for the matter of
bringing the old docs up to date, modifier trains have very little
interest to most J users.
I think anyone using modifier trains will be able to distinguish ]:
from [: .
Henry Rich
On 9/29/2021 12:09 PM, 'Pascal Jasmin' via Programming wrote:
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
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
