[Jprogramming] C0 C1, and tacit modifier forks WAS: New in beta-r: old stuff

[Henry Rich]

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 <henryhrich at gmail.com> 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