The (a v) train was an idea from Viktor Cerovski that I believe was mainly
motivated by the desire for a tacit "dynamic rank". See
http://www.jsoftware.com/pipermail/programming/2010-November/021108.htmlfor
the discussion.

Pascal is correct, the parsing rules can get "unintuitive" although the
rules were not changed it is simply a bident that gets swallowed up instead
of spit out:

   / +
/ +

   / + +
(/ +) +

   / + + +
/ (+ + +)

   / + + + +
(/ +) (+ + +)

NB. Looks like a game of even and odds

It works well for " ~ !. !: d. D: L: S: t. t: . The other contenders } ^:
@. already accept verbs or gerunds so I don't see much use for them.

I believe in a majority (maybe others have different use cases) of the
dyadic applications the intention is to pass the adverb's noun argument as
either X or Y and not make it depend on both X and Y. So in

X ((f c) v) Y

where c is " S: L: etc., most of the time you have

f =: f_verb @ ]
v=: v_verb @ [

If you actually want to call f_verb dyadically you still have to embed the
dynamic noun argument into X and/or Y and most of the time you don't want
that to be input to f_verb as well, so you end up just do something like

f=: f_dyad / @ ]

Now consider dynamic fit !. Fit must apply to f_verb or f_dyad and not f.
So it doesn't seem possible to me to use unless you can derive the fit from
one of the arguments to your underlying verb. But I haven't discovered a
practical use yet for something like

   3 (({.!.) [) 0
0 3 3

My suggested "improvement" would be to change the dyadic definition to

X (a v) Y => (v X) a Y

That cleans up the monadic cases so that f in (f a) doesn't need to be
modified and also makes monadic application of fit work. For dyadic f you
will still need to do something like N (((f /) c) v) X,Y.And if you do want
v to be applied dyadically you can use the fork

(v (a [) ])

Dyadic fit will still not work though.To fix that my (wacky!?) ideas are:
0. Leave it and don't worry about fit or the extra convenience of X (a v) Y
=> (v X) a Y on monadic applications
1. Drop the train altogether and follow Pepe's suggestions
2. Define something like X (a (f ` g ` h)) Y => (g Y) (f X) a (h Y),
3. Let fit work on f @: g, f @ g etc. and push the fit into f
4. Just change the implementations directly of " S: L: !. etc. to work the
way you want them to
5. Invent triadic verbs by placing the third argument underneath the verb:

X + Y
   Z



On Sun, Mar 9, 2014 at 5:58 PM, Jose Mario Quintana <
[email protected]> wrote:

> By the way, we might drop or modify the (adverb verb) train in the near
> future; because, given the other extensions, its ability to refer to the
> noun arguments (x and y) is no longer crucial. Thomas has some thoughts
> about this.
>
>
>
>
>
>
> On Sun, Mar 9, 2014 at 3:53 PM, Jose Mario Quintana <
> [email protected]> wrote:
>
> > If you have access to a Windows environment you can simply overwrite the
> > j.dll (after making a backup, of course!) with the one provided at the
> page
> > referred in my first post; also, you can have a look at the Cheatsheet
> > provided in the same page.  The Cheatsheet shows, among other items, the
> > full parsing table including the extensions.  Meanwhile,
> >
> >    / @ / *
> > / @ /*
> > ┌───────┬─┐
> > │┌─┬─┬─┐│*│
> > ││/│@│/││ │
> > │└─┴─┴─┘│ │
> > └───────┴─┘
> >
> >
> >
> > On Sun, Mar 9, 2014 at 8:50 AM, Pascal Jasmin <[email protected]
> >wrote:
> >
> >> I can answer that these all replace domain errors.  I cannot try the
> >> patch yet.
> >>
> >> patches 3 and 4 may conflict with each other though probably not.
> >>
> >> (a c a v)  could/should be an adverb train.  ((a c a) v) -> c v (or? a
> (c
> >> (a v)))
> >>
> >> (a c a v v) might be ambiguous too.  I find patch 3 more useful and
> >> intuitive than patch 4, and I assume that c v v still binds as (c v) v,
> in
> >> which case it retains the above intuitiveness, but I could see problems
> >> with (a v v v v v... v)
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: bill lam <[email protected]>
> >> To: [email protected]
> >> Cc:
> >> Sent: Sunday, March 9, 2014 12:06:18 AM
> >> Subject: Re: [Jprogramming] J Extensions
> >>
> >> Will it change current J semantics or break existing code?
> >> If it is compatible with current J701 engine, I'll try to add
> >> it into android libj.so which is also GPL licensed.
> >>
> >> Is there any test suite for the extensions?  Actually I don't
> >> understand those extensions, sorry to be slow.
> >>
> >> Сб, 08 мар 2014, Jose Mario Quintana писал(а):
> >> >  The patches, a Windows 32-bit DLL, a cheatsheet, 32 and 64 bit Unix
> >> > libraries are found at:
> >> >
> >> >
> >> >  http://www.2bestsystems.com/foundation/j/
> >> >
> >> >
> >> >  For more details and demonstration code, see the article in the
> >> Journal of
> >> > J: http://journalofj.com/index.php/vol-2-no-2-october-2013 (only the
> >> > definition of the new conjunction knot (`.) has been slightly modified
> >> for
> >> > the release).
> >> > ----------------------------------------------------------------------
> >> > For information about J forums see
> http://www.jsoftware.com/forums.htm
> >>
> >> --
> >> regards,
> >> ====================================================
> >> GPG key 1024D/4434BAB3 2008-08-24
> >> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> >> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> >>
> >> ----------------------------------------------------------------------
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> >> ----------------------------------------------------------------------
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> >>
> >
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to