> 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:
This is a good (something I agree with) general rule. Let's let U stand for V/N. I wouldn't use the word fork for bound conjunctions, and would reword the rule as Auto-pair Us to Cs when possible, or not superceded by other/longer rule. With CUC autopaired as (CU)C to disambiguate. Gains from this approach include recursive autopairing of conjunctions as "double adverbs" - +: @ -> +:@- or even double parameters to right of conjunction if A U -> U A The disadvantage of such a rule is that it would interfere with some of the new train production modifiers. But this is fixed with my proposals CC -> (uC1v)C2 AC -> uA(Cv) its possible to create a train with a "floating adverb or conjunction" anywhere within the train - (@ `)(+/`)(`:6) % -> (-@% `)(+/`)(`:6) and # - (@ `)(+/`)(`:6) % -> +/ -@% # or - (@ (`#))((+/)`)(`:6) % +/ -@% # and with auto-pairing, this could even be written as @`# (+/)` `:6 which would make writing such trains-by-modifiers relatively easy even if it eliminated the defined ones. The A V (VV..V) train is already quite easy to make without the rule A(`V)(`V)(`:6) NB. can also be paren free with auto pairing rules. On Wednesday, October 6, 2021, 05:17:53 a.m. EDT, Hauke Rehr <[email protected]> wrote: 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
