if you went with your original proposal, I can still do what I want/need with
the following "fake conjunction" abomination
FC =: 1 : ' 2 : ('' ([. '', u , '' ].)'') '
+ ('@' FC) -
[. @ ].
= + '@' FC - *
=@*
if in (u C0 v '@'FC), u C0 v produces a (valid modifier input) u , then (u C0
v) (u '@'FC v) will be an adverb and same u2 binds it.
On Wednesday, September 29, 2021, 12:39:57 p.m. EDT, Henry Rich
<[email protected]> wrote:
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
>>
>
--
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
