Yes, > ((<,'/')`(<(<,'@')`(<<g`h)))`:6
>
> /(@(g h))

Excellent, thanks!  I had the feeling that there could be such a form but I
could not find it quickly late last night.

> So your D2 definition is already part of the implementation.

Yes, the point of D2 is to legitimize a useful bug/feature of the current
implementation; so, it would be regarded as just a feature (not a bug) and
it would be preserved.


On Thu, Mar 19, 2020 at 10:14 AM 'Pascal Jasmin' via Programming <
programm...@jsoftware.com> wrote:
>
> Your interesting new example is
>
>   (<,'/')`(<(<,'@')`(<(<,'2'),<g`h))`:6
> /(@(g h))
>
> The explicit hook indicator (2) seems needed here because it seems hard
to weave extra boxing levels without the hook indicator, but there is such
a form:
>
> ((<,'/')`(<(<,'@')`(<<g`h)))`:6
>
> /(@(g h))
>
> ((;:'/@'),(g`h))@.(0 ; < 1 ; << 2 3)
>
> /(@(g h))
>
> So your D2 definition is already part of the implementation.
>
> Still, in constructing gerrunds/ARs, the advice to use the verb train
indicators when that is the intention seems recommendable/safe, though if
every train has a nested representation (I need more thought to evaluate)
then there'd be no reason to use the safe approach, and perhaps no reason
to not represent train ARs with nesting levels.
>
>
>
>
>
> On Wednesday, March 18, 2020, 11:52:16 p.m. EDT, Jose Mario Quintana <
jose.mario.quint...@gmail.com> wrote:
>
>
>
>
>
> > You are suggesting that a list of ARs be construed as a valid AR.
>
> No, I would not dare to mess with the description of what an AR is.
> Probably the source of the confusion was my unfortunate use of the phrases
> "M represents R" when I just meant "The product of M `:6 is R."  What I am
> suggesting is to extend the description of what a kosher argument (m) is
in
> (m`:6).  (Its valid boxed structure would be similar to the one for a
> (current) kosher argument (n) in (m@.n).)
>
> This is a more precise recursive description of the construction of a
> kosher argument (m) in (m`:6) assuming D2 holds:
>
>   A <kosher argument> is,
>
>   0. An AR, or
>
>   1. A list of one or more <kosher argument>s, or
>
>   2. A boxed <kosher argument>.
>
> If (2) above is not included then it becomes the description of the
> construction of a valid argument assuming D1 holds (if I am not mistaken).
> (If one replaces (AR) above by (integer) then, I think, it becomes a
> description of the construction of a (current) kosher argument (n) in (m@
> .n).)
>
> Hopefully, answering the question (and it is a very good question) you
> posed might clarify further what I am trying to convey.  Assuming (g) and
> (h) are verbs, if (f) is a verb then,
>
>   f`(<g`h)
> ┌─┬─────┐
> │f│┌─┬─┐│
> │ ││g│h││
> │ │└─┴─┘│
> └─┴─────┘
>   f`(<g`h) `: 6
> f (g h)
>
> This argument is not a list of ARs regardless if one is assuming D1 or D2.
> It is not kosher assuming D1 but it is assuming D2.  Likewise, if (f) is a
> conjunction, say (@), then,
>
>   (<,'@')`(<g`h)
> ┌─┬─────┐
> │@│┌─┬─┐│
> │ ││g│h││
> │ │└─┴─┘│
> └─┴─────┘
> (<,'@')`(<g`h) `:6
> @(g h)
>
> Again, this argument is not a list of ARs regardless if one is assuming D1
> or D2.  It is not kosher assuming D1 but it is assuming D2.  In addition,
> in both scenarios (if (f) is a verb or (f) is a conjunction) the product,
> assuming D2, can be thought as a train of two entities, the trailing one
> being a derived entity (g h).
>
> In contrast, the boxed form of ((<,'@')`(<g`h)),
>
>   <(<,'@')`(<g`h)
> ┌─────────┐
> │┌─┬─────┐│
> ││@│┌─┬─┐││
> ││ ││g│h│││
> ││ │└─┴─┘││
> │└─┴─────┘│
> └─────────┘
>   (<(<,'@')`(<g`h)) `:6
> g@h
>
> Is the AR of g@h and it is kosher assuming D1 (and, of course assuming D2
> as well).  Furthermore, one can simply use,
>
>   (;:'g@h')
> ┌─┬─┬─┐
> │g│@│h│
> └─┴─┴─┘
>   (;:'g@h') `:6
> g@h
>
> the result is the same but it is produced as the train of three entities.
>
> A remaining question is, why the result of ((<(<,'@')`(<g`h)) `:6) is not
> (@(g h))? Apparently, the interpreter gives priority to ARs.
>
> > I don't like having to parse the ARs to figure out how to interpret
them.
>
> What is the interpreter doing now?  I do not know...  Maybe you can let us
> know?
>
> How would one produce, for instance, (/(@g h)) then?  One way is to use
the
> AR of (u v),
>
>   (<,'/')`(<(<,'@')`(<(<,'2'),<g`h))
> ┌─┬─────────────┐
> │/│┌─┬─────────┐│
> │ ││@│┌─┬─────┐││
> │ ││ ││2│┌─┬─┐│││
> │ ││ ││ ││g│h││││
> │ ││ ││ │└─┴─┘│││
> │ ││ │└─┴─────┘││
> │ │└─┴─────────┘│
> └─┴─────────────┘
>   (<,'/')`(<(<,'@')`(<(<,'2'),<g`h)) `:6
> /(@(g h))
>
> The above is just an elaborated version of Pascal's answer given
> earlier.  Thinking
> more about it, if D2 were adopted, I do not think any text in NuVoc would
> have to be changed regarding tie (`), not even the description of gerund
> unless one would like to refer to (m) in m`:6 as a gerund.  The agenda
(@.)
> entry of the Dictionary would have to be understood accordingly as well.
>
> I hope it helps.
>
>
-----------------------------------------------------------------------------
>
>
> On Tue, Mar 17, 2020 at 10:46 AM Henry Rich <henryhr...@gmail.com> wrote:
> >
> > You are suggesting that a list of ARs be construed as a valid AR.  I
> > agree with the goal.  I worry that the encoding is not reversible.
> >
> > +---------+
> > |+-+-----+|
> > ||f|+-+-+||
> > || ||g|h|||
> > || |+-+-+||
> > |+-+-----+|
> > +---------+
> >
> > Is this (f (g h))  (as it must be if f is a verb)
> > or  (g f h)  (if f is a conjunction)?
> >
> > I don't like having to parse the ARs to figure out how to interpret
them.
> >
> > Henry Rich
> >
> >
> > On 3/16/2020 10:18 PM, Jose Mario Quintana wrote:
> > >> I would say that (<,'"') is kosher and (<'"') not, already, based on
> > >> this interpretation of what Ye Dic meant.  The implementation is
> > > I am adopting your suggestion henceforth.
> > >
> > >> My vote would be that 'train' refers to any sequence of ARs and that
> > >> when `:6 said 'train of individual verbs' it meant to say 'the
> (possibly
> > >> derived) words created by executing the train of the (possibly
derived)
> > >> words represented by each AR'.
> > > So,
> > >
> > > D0. m `: 6  Train  Result is the train of individual verbs.
> > >
> > > would become (or be understood as),
> > >
> > > D1. m `: 6  Train  Result is the (possibly derived)
> > >                    words created by executing the train
> > >                    of the (possibly derived) words
> > >                    represented by each AR.
> > >
> > > I have thought more about this and I am not quite sure about the
wisdom
> of
> > > banning, eventually (when the negligence rather than benevolence
stops),
> > > the boxed arrays of ARs currently supported by the interpreter.  My
> > > perspective comes from the tacit adverbial programer's viewport which
> will
> > > try to explain next assuming that D1 is the law (i.e., henceforth
kosher
> > > also implies compliance with D1).
> > >
> > > If the argument of (`:6) is a list of ARs of primary parts-of-speech,
> (`:6)
> > > produces the non-parenthesized (i.e., with the parsing rules implied
> > > parenthesization) train of the corresponding primary
> parts-of-the-speech.
> > > However, when its argument is boxed the interpreter's result is the
> train
> > > which is parenthesized accordingly, and this is not kosher.
> > >
> > > How can this extra illegal flexibility be important to a tacit
adverbial
> > > programmer?  Consider the following slight variation of my
> general-purpose
> > > generator of tacit adverbs (hg),
> > >
> > >    o=. @:
> > >    c=."_
> > >    ar=. 5!:1@:<
> > >
> > >    d=. (a0=. `'') (a1=. (@:[) ((<,'&')`) (`:6)) (a2=. (`(<(":0);_))
> (`:6))
> > >    av=. ((ar'a0')`)  (`(ar'a1')) (`(ar'a2') ) (`:6)
> > >      assert 1 4 9 -: 1 2 3 *: av
> > >
> > > The only change was replacing (<'&') by (<,'&') (this does not me too
> > > much).  I think its construction and operation is kosher; ye, The Wise
> of
> > > J, be the judges.
> > >
> > > The last part of (hg)'s construction is unchanged,
> > >
> > > aw=. < o ((0;1;0)&{::)  NB. Fetching the atomic representation
> > > d=. (a3=. (@: (aw f.)) ('av'f.)) (a4=. "_) (a5=. `:6)
> > > a6=. ((( ar'a4') ; ] ; ( ar'a3')"_) ('av'f.)) (`:6)
> > >
> > > hg=. `((ar'a6')`(ar'a5')) (`:6)
> > >
> > > Again, if I am not mistaken, (hg)'s construction is kosher.  However,
> > > whether its operation is kosher, or not, depends on its controlling
> (tacit)
> > > verb argument.  This verb operates on the AR of the argument of the
> > > generated adverb and, I believe, if (and only if) it produces the AR,
> or a
> > > list of AR(s), representing the desired product, then it is kosher.
Two
> > > toy examples follow, one simple and another slightly more complicated.
> > >
> > > One can use (hg) to generate an adverb (a) which is meant to take a
> > > non-parenthesized train of two or more proverbs and produce the verb
> where
> > > (@:) is inserted between the proverbs,
> > >
> > >    a=. ([ , (<,'@:') , ])/ o (((3 = ]) +. (_1 = ])) o (4!:0) # ]) o
> (<S:0)
> > > f.hg
> > >
> > > This tacit fixed adverb operates in a kosher manner,
> > >
> > >    (v0 v1 v2 v3 v4 v5 v6)a
> > > v0@:v1@:v2@:v3@:v4@:v5@:v6
> > >
> > > since the train produced is non-parenthesized. (If I am not mistaken.)
> > >
> > > In contrast, the following tacit fixed adverb (b) which generates an
> adverb
> > > that produces a train of adverbs by bonding accordingly its list of
> > > integers argument,
> > >
> > >    an=.  <@:((,'0') ,&:< ])
> > >
> > >    b=. (< o ((;:'&') , <) o an"0) o x: o (('';1)&{::) f.hg
> > >
> > > does not operate in a kosher manner (and eventually it will fail),
> > >
> > >      _2 3 _1 b
> > > ((&_2x)(&3x))(&_1x)
> > >
> > >    +_2 3 _1 b 0 1 3 4 5 6
> > > _1 5 17 _31 65 _127
> > >
> > > and its kosher counterpart would be more complicated (because of the
> > > produced train parenthesization) when one does not need any additional
> > > complications.  (If I am not mistaken.)
> > >
> > > It might be due to trickery but this current behavior of the
interpreter
> > > comes across as a very useful feature from this perspective.  I see a
> > > benefit if it is preserved and I cannot see a disadvantage.  Thus,
> assuming
> > > I am not missing something important, I would like to offer my two
> cents,
> > >
> > > D2. m `: 6  Train  Result is the (possibly derived)
> > >              words created by executing the train of the
> > >              (possibly derived) words represented by
> > >              each AR.  If m is boxed, the boxed trains
> > >              are parenthesized accordingly.
> > >
> > > which is the same as D2 plus a fragment which was taken, almost
> verbatim,
> > > from the (@.) entry.
> > >
> > > Igor Zhuravlov's 3-fork, for instance, is represented by,
> > >
> > >    (<v3 ` v1 ` v4) ` v0 ` (<v4 ` v2 ` v5)
> > > ┌──────────┬──┬──────────┐
> > > │┌──┬──┬──┐│v0│┌──┬──┬──┐│
> > > ││v3│v1│v4││  ││v4│v2│v5││
> > > │└──┴──┴──┘│  │└──┴──┴──┘│
> > > └──────────┴──┴──────────┘
> > >
> > >    (<v3 ` v1 ` v4) ` v0 ` (<v4 ` v2 ` v5) (`:6)
> > > (v3 v1 v4) v0 v4 v2 v5
> > >
> > > whereas, assuming D1, it is represented by (ye fill the blank),
> > >
> > > ...
> > >
> > > Either way, regardless of what is ultimately decided, I think, the
(@.)
> and
> > > (`) entries should be modified accordingly (I do not know about the
> concept
> > > of gerund).
> > >
> > >
>
------------------------------------------------------------------------------
> > >
> > >
> > > On Fri, Mar 13, 2020 at 11:40 AM Henry Rich <henryhr...@gmail.com>
> wrote:
> > >> I think I agree.
> > >>
> > >> My vote would be that 'train' refers to any sequence of ARs and that
> > >> when `:6 said 'train of individual verbs' it meant to say 'the
> (possibly
> > >> derived) words created by executing the train of the (possibly
derived)
> > >> words represented by each AR'.
> > >>
> > >> I would say that (<,'"') is kosher and (<'"') not, already, based on
> > >> this interpretation of what Ye Dic meant.  The implementation is
> > >> permissive in some cases.
> > >>
> > >> Henry Rich
> ----------------------------------------------------------------------
> 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