Note that another option for passing modifiers as arguments would be
to use placeholder verbs as arguments to the modifiers and then
passing the resulting verb.
As long as the placeholders are identifiable, they can then be easily replaced.
For example, given:
genid=:({~ ?@#~@#)@((#~_1<:nc@<"0)a.)"0
We could generate three identifiers which could be used as
placeholders for some modifier which needs to be an argument
somewhere:
genid i.3
wImlUpMmbmTiSXobxDIPECYcWgcvrwPSZZTrLvkaClrrsfhvElwm
NVqCcxbHYowuVKzzaKsuebujPqNHwjJMUKlabjCckyydIxGsCAaG
nIbMGYCrsnotqrMPKMJtQQHGmCIgFMXtGfomdZcYswFRQnaDUNdx
(This particular implementation gives us 103 bits of randomness, so
the chance of a collision between two identifiers is about 1 in 3e15
and your chances of a memory error hitting the program are higher than
that.)
That said, since linear representation is currently not reliable, you
presumably still wind up using atomic representation during the
substitution process.
Thanks,
--
Raul
On Mon, Mar 9, 2020 at 2:30 PM 'Pascal Jasmin' via Programming
<programm...@jsoftware.com> wrote:
>
> A shorter version of Jose's argument.
>
> Functional programming requires the ability to pass functions as arguments.
> A missing feature in J is to pass modifiers as arguments, and atomic
> representations is the best (or at least a very good) way of getting around
> that limitation.
>
> examples of Jose's "illegal" LRs are
>
> (`_) NB. not strictly illegal, but will not produce the AR of _ when the only
> valid argument to the adverb is given (a numeric value)
>
> (`&) NB. illegal as it is not an adverb train.
>
> The intent (and internal representation without the LR bug) of both of the
> above is
>
> `(<(,'0');_) and `(<'&')
>
> The simplest fix is that LR reflect the actual ARs it is representing, such
> that evoking it results in the same internal representation the LR is
> displaying.
>
> An enhancement with no real downsides is `(noun that is not an AR/gerund)
> results in the AR of that noun being appended to an AR of argument to its
> left. The justification for the enhancement is that (`_) is prettier than
> `(<(,'0');_)
>
> The simplest fix only is entirely acceptable, though.
>
> It would also be possible to make (`&) legal with the following trains (and
> parsing change that creates ambivalent modifiers). With usefulness that goes
> beyond (`&) legality.
>
> u (a c) --- ((u a) c) an adverb implies v u (a c) --- (u a) (c v) NB.
> double adverb form
>
> u (a c) v --- (u a)(v c)
>
> u (c a) --- (u c) a = adverb that implies v u (c a) --- (u c v) a
>
> u (c a) v --- (c (v a)) is created first, also an adverb, and so u (c a) v
> ---- (u c (v a))
>
> it follows that
>
> u1 (c1 c2) --- creates (a c) train ((u1 c1) c2)
> u2 u1 (c1 c2) --- ((u1 c1 u2)c2 )
> u1 (c1 c2) v ---- (u1 c1) (v c2) implies u2 u1 (c1 c2) v == (u1 c1 u2) (v c2)
> . NB. (c1 c2) v is the (c a) pattern of (c1 (v c2))
> u3 u2 u1 (c1 c2) --- (u1 c1 u2)(c2 u3) where last step is u3 (u1 c1 u2 c2)
> (c1 c2) v1 v2 --- (c1 (v1 c2 v2)) consistent with above and (a c) v pattern
> earlier. (c1 (v1 c2)) v
>
>
> There are some missing binding combinations. These could be filled in with
> gerund forms where '' indicates unbound in position, but a better system one
> paragraph later than next.
>
> These rules extend to unlimited combinations of a and c as part of trains.
> They are simpler than they may appear. u parameter list binds right to left
> to modifiers from left to right. The v parameter list binds from left to
> right to modifiers from right to left (all bound on left side of modifier).
> All of the v bind before any of the u.
>
> One way to bypass these binding rules would be the rule that ([: modifier)
> returns the modifier unchanged, and so there would be a mechanism to bypass
> the binding orders. ([: c v) or v ([: c) returns (c v), and then u [: (a c)
> returns ([:a)(u c) which is a(u c)
>
> For parsing ambivalent modifiers, parenthesizing their partial bindings would
> remove ambiguity, though that is not usually needed with existing parser.
>
> (2) 3 (2 : '[+u+v+]') 4 (1)
>
> 10
>
> Some examples of longer chains
>
> u3 u2 u1 (c1 a1 c2 c3 a2) --- ((u1 c1 u2) a1 (c2 u3) c3) a2 NB. result is
> adverb train of 2 adverbs
> u2 u1 (c1 a1 c2 c3 a2) v1 v2 --- (u1 c1 u2) a1 c2 (v2 c3 (v1 a2)) NB.
> results in fully/dual bound c2.
> u (c1 a1 c2 c3 a2) [: [: v1 [: v2 v3 -- u c1 (v3 a1) ([: c2 v2) ([: c3 v1)
> ([: a2) -- ((u c1 (v3 a1) c2 v2 c3 v1)a2
>
> The above results assume that modifiers return non-modifier results, but the
> proposal doesn't need that behaviour. New modifier results are simply a new
> modifier train that consume the next parameter with the same rules. In fact,
> ([: modifier) returns a modifier
>
>
> > P.S. I will try to provide an answer with details during the weekend.
>
> I am describing details of the system that I would like to have or keep,
> and why. Since this is a forum I am providing repetitive background
> information for the potential benefit of other members. An important
> motivation for me is to be able to write a wide class of tacit adverbs
> without much aggravation. One can write legally (sanctioned, or at least
> not forbidden, by the current official documentation) simple useful tacit
> adverbs; for example,
>
> for=. ("1)(@:(>@:{))
>
> u for
> u"1@:(>@:{)
>
> However, it is not easy to legally write (that is, produce) tacit words
> (i.e., verbs, adverbs, conjunctions or plain nouns) with added
> complications. Even simple constructions, which apparently are still
> allowed by the interpreters (admittedly, I have not played much with the
> J901 or with the J807 engines), using tie (`), train (`:6), and agenda (@.),
> are regarded as illegal by the official documentation (NuVoc) as I read it;
> for example,
>
> 9!:14''
> j901/j64/windows/release-e/commercial/www.jsoftware.com/2020-01-29T11:13:46
>
> an=. <@:((,'0') ,&:< ])f. NB. Atomizing nouns (monadic verb)
>
> (<,'"') ` (an 1) (`:6)
> "1
> (<,'"') ` (an 1) @. 0 1
> "1
>
> They are considered illegal because,
>
> - The left argument of tie (<,'"') is not the atomic representation (AR)
> of a verb.
>
> - I that context, both, train and agenda do not produce a verb.
>
> Why are those restrictions necessary? I am not aware of any compelling
> reason(s), on the contrary (of course, I am always willing to be
> educated). Assume that we want to produce a slightly more complicated
> (double) tacit adverb (a) such that,
>
> u`v a
> (u@:v - v@:u)"
>
> _1 *:`(+/) a i. 2 3 4
> 64 118 184 262
> 1504 1702 1912 2134
>
> Disregarding restrictions one can simply define this adverb as,
>
> a=. (`(;:'@:-"'))(@.(4 ;~ (<0 2 1 3 1 2 0)))
>
> By the way,
> a
> (`(@:`-`"))(@.((<<0 2 1 3 1 2 0),<4))
>
> (`(@:`-`"))(@.((<<0 2 1 3 1 2 0),<4))
> |syntax error
> | (`( @:`-`"))(@.((<<0 2 1 3 1 2 0),<4))
>
> Cumbersome, or otherwise, this method allows one to write tacit adverbs
> which function as parameterized macros.
>
> There is a more general method. It is possible (again, disregarding the
> restrictions aforementioned) to write (tacitly) complex tacit adverbs using
> a tacit adverb (hg), which takes a (tacit) verb as an argument. One can
> produce a wide class of tacit adverbs by varying its (tacit verb) argument.
>
> The adverb a2, which I used to show a manifestation of a linear
> representation (LR) bug earlier in this thread, is a component of hg; the
> definition of hg follows,
>
> o=. @:
> c=."_
> ar=. 5!:1@:<
>
> d=. (a0=. `'') (a1=. (@:[) ((<'&')`) (`:6)) (a2=. (`(<(":0);_)) (`:6))
> av=. ((ar'a0')`) (`(ar'a1')) (`(ar'a2') ) (`:6)
> NB. Adverbing a monadic verb (adv)
> assert 1 4 9 -: 1 2 3 *: av
>
> 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)
>
> In addition to a2, many other components of hg, and hg itself have faulty
> LRs,
>
> a1
> ((@:[)(&`))(`:6)
> a2
> (`_)(`:6)
> .
> .
> .
>
> av
> (((`''`)(`(((@:[)(&`))(`:6))))(`((`_)(`:6))))(`:6)
> .
> .
> .
>
> hg
> (`((((`'')(&(((<(<,'4'),<(<,'"'),<(,'0');_) ; ] ;
> (<(<,'4'),<(<(<,'4'),<(<'@:'),<(<'@:'),<(<,'<'),<(<,'&'),<(<(<,'0'),<0;1;0),<'{::'),<(<,'4'),<(<(<,'4'),<(<(<,'4'),<(<(<,'4'),<(<(<,'0'),<<(<,'4'),<(<,'`'),<<;._1
> ' 0 '),<,'`'),<(<,'4'),<(<,'`'),<(<,'0'),<<...
>
> This makes writing adverbs such as hg more difficult than it should be.
> So, I would like,
>
> 0. To have proper LRs for the components of hg and similar adverbs.
>
> Are all of the above faulty LRs manifestations of the same bug? Probably,
> but I am not in a position that would allow me to tell you with certainty.
> This would be the only suggested change to the behavior of the interpreter.
>
> Many years ago, when I wrote hg at the request of Dan Bron, we thought it
> was legal; unfortunately, now apparently it is not; so, I would like,
> ideally,
>
> 1. All the components of hg, and similar components, to be regarded as
> legal.
>
> This would imply, for instance, that (ar'a6')`(ar'a5') is a legal use of
> tie (`) and, tying ARs and similar forms (see below) would be considered
> legal as well.
>
> It is grammatically correct for an adverb to produce any kind of word.
> Therefore, that is not a reason to regard the primary products (adverbs) of
> hg as illegal,
>
> a=. v hg
> type'a'
> ┌──────┐
> │adverb│
> └──────┘
>
> The adverb (a) produces a word associated with the AR, or similar, which is
> the result of the verb v applied to the AR of (a)`s argument.
>
> Therefore, I would like,
>
> 2. The past (and current?) behavior of (`:6) and @. (and `) to be
> regarded as legal.
>
> (Ultimately the legality of the constructions would be irrelevant, as far
> as I am concerned, as long as its functionality is preserved.)
>
> The adverb hg can also produce tacit adverbs which function as
> parameterized macros; continuing with the same example, one would just
> need, given the AR of the adverb's argument,
>
> (u`v) an hg
> ┌─────────┐
> │┌─┬─────┐│
> ││0│┌─┬─┐││
> ││ ││u│v│││
> ││ │└─┴─┘││
> │└─┴─────┘│
> └─────────┘
>
> to write a (tacit) verb which would produce the AR of the desired result;
> that is,
>
> d=. (u@:v - v@:u)"
> ar'd'
> ┌─────────────────────────────────────┐
> │┌─┬─────────────────────────────────┐│
> ││4│┌─────────────────────────────┬─┐││
> ││ ││┌─┬─────────────────────────┐│"│││
> ││ │││3│┌──────────┬─┬──────────┐││ │││
> ││ │││ ││┌──┬─────┐│-│┌──┬─────┐│││ │││
> ││ │││ │││@:│┌─┬─┐││ ││@:│┌─┬─┐││││ │││
> ││ │││ │││ ││u│v│││ ││ ││v│u│││││ │││
> ││ │││ │││ │└─┴─┘││ ││ │└─┴─┘││││ │││
> ││ │││ ││└──┴─────┘│ │└──┴─────┘│││ │││
> ││ │││ │└──────────┴─┴──────────┘││ │││
> ││ ││└─┴─────────────────────────┘│ │││
> ││ │└─────────────────────────────┴─┘││
> │└─┴─────────────────────────────────┘│
> └─────────────────────────────────────┘
>
> but that would be the hard way. The easy way is to produce a similar form
> implied by the agenda in the previous solution, namely,
>
> (u`v) an o ('"' ;~ ]) o (([ , '@:' ; ] , '-' ; ] , '@:' ; [)/) o
> (('';1)&{::)hg
> ┌─────────────────┬─┐
> │┌─┬──┬─┬─┬─┬──┬─┐│"│
> ││u│@:│v│-│v│@:│u││ │
> │└─┴──┴─┴─┴─┴──┴─┘│ │
> └─────────────────┴─┘
>
> Thus, one can reproduce the adverb (a) using hg as follows,
>
> a=. ('"' ;~ ]) o (([ , '@:' ; ] , '-' ; ] , '@:' ; [)/) o (('';1)&{::)hg
>
> indeed,
>
> u`v a
> (u@:v - v@:u)"
>
> _1 *:`(+/) a i. 2 3 4
> 64 118 184 262
> 1504 1702 1912 2134
>
> (It should not be a surprise by now that this version of (a) also has a
> faulty LR.)
>
> In addition, the adverb hg can produce adverbs which can compute verbs; for
> instance, fast growing functions (do not try the 4 b variants; unless you
> like to watch a zombie j),
>
> b=. (< o ((;:'&') , <) o an"0) o x: o (3 + i.) o (('';1)&{::) f.hg
>
> + 3 b 0 1 2
> 5 19 61
> * 3 b 0 1 2
> 5 972
> 2311636689599124105290248227248346311907805731599025040424058727845362278706486831678549034616390931929990722740950483148706576493125959644408795745069851838858348082593920080669882260917889638613299807576081950958129855915252733008332811030412805596...
>
> Similar forms to ARs can be defined recursively; since this post is already
> too long, I will not go into details but the following is a standard
> counterpart (apart from the theoretical restrictions) of a wicked version,
>
> ". noun define -. CRLF NB. Fixed tacit code...
>
> recur=.
>
> (_1 |. 0 = 1 _1 0 +/\@:{~ (;:'()') i. ])(an f.)@:".^:(('''' = {.)
> +. (':' ~: {:) *. '_0123456789' e.~ {.)@:;&.:>`(<@:$:@:}.@:}:)@.(
> (;:'()') -: {. , {:);.1 ]
>
> )
> tail=. (}:^:('NB.' -: 3 {. >@:{:))@:;:
> as=. , o recur o tail NB. "atomizing" sentences
>
> Tie, train, and agenda can handle this kind of "atomized" sentences,
>
> (as'((*:@:(+/) - +/@:*:)@:i.) NB. verb') ` (as '(2 * (3 + 4)) NB. noun')
> ┌─────────────────────────────────┬───────────────────────────────┐
> │┌─────────────────────────┬──┬──┐│┌───────┬─┬───────────────────┐│
> ││┌──┬──┬─────┬─┬─┬─┬──┬──┐│@:│i.│││┌─────┐│*│┌───────┬─┬───────┐││
> │││*:│@:│┌─┬─┐│-│+│/│@:│*:││ │ ││││┌─┬─┐││ ││┌─────┐│+│┌─────┐│││
> │││ │ ││+│/││ │ │ │ │ ││ │ │││││0│2│││ │││┌─┬─┐││ ││┌─┬─┐││││
> │││ │ │└─┴─┘│ │ │ │ │ ││ │ ││││└─┴─┘││ ││││0│3│││ │││0│4│││││
> ││└──┴──┴─────┴─┴─┴─┴──┴──┘│ │ │││└─────┘│ │││└─┴─┘││ ││└─┴─┘││││
> │└─────────────────────────┴──┴──┘││ │ ││└─────┘│ │└─────┘│││
> │ ││ │ │└───────┴─┴───────┘││
> │ │└───────┴─┴───────────────────┘│
> └─────────────────────────────────┴───────────────────────────────┘
>
> (as'((*:@:(+/) - +/@:*:)@:i.)') ` (as '(2 * (3 + 4))') (`:6)
> 7462
> (as'((*:@:(+/) - +/@:*:)@:i.)') ` (as '(2 * (3 + 4))') @. 0 1
> 7462
>
> ((*:@:(+/) - +/@:*:)@:i.) (2 * (3 + 4))
> 7462
>
> The verb (as) borrows concepts and even code from Dan's original anonymous
> evoke (ae) adverb; its source code seems to be missing in action but the
> following is an alternative derivation by means of (as) and (hg),
>
> ae=. as o (('';1)&{::) hg
>
> '(*:@:(+/) - +/@:*:)@:i.' ae
> (*:@:(+/) - +/@:*:)@:i.
>
>
> Are all the forms that can be handled covered? Not necessarily.
>
>
> > > Note that getting useful linear representations from 5!:5 becomes
> > > significantly harder if it must also represent nouns which contain
> > > non-nouns.
> >
> > No, I was not necessarily referring to wicked (non-standard) nouns
>
> Alright, now I will be referring to wicked (non-standard) programming. Why
> do I care about nouns which contain verbs, adverbs and conjunctions (as
> opposed to only noun representations), adverbs and conjunctions cloaking as
> verbs, and many other goodly creatures?
>
> With this kind of entities one can produce tacit adverbs which in turn can
> refer tacitly to the arguments of the verbs they produce; one can also
> produce recursive verbs which can be fixed without losing their meaning
> (e.g., the wicked version of the verb (as), as opposed to its counterpart
> entertained here,
>
> as'(*:@:(+/) - +/@:*:)@:i.'
> ┌─────────────────────────┬──┬──┐
> │┌──┬──┬─────┬─┬─┬─┬──┬──┐│@:│i.│
> ││*:│@:│┌─┬─┐│-│+│/│@:│*:││ │ │
> ││ │ ││+│/││ │ │ │ │ ││ │ │
> ││ │ │└─┴─┘│ │ │ │ │ ││ │ │
> │└──┴──┴─────┴─┴─┴─┴──┴──┘│ │ │
> └─────────────────────────┴──┴──┘
> as f.'(*:@:(+/) - +/@:*:)@:i.'
> 1 1
>
> )
>
> This matters to me because I have been running a system using custom
> interpreters for many years. It is tacit and fixed (in the (f.) sense of
> the word) and it is produced with fixed tacit tools, no names imply no
> names conflicts. Contrary to common wisdom, it has been easy to write and
> to update (even while it is running). If only for those reasons, I would
> continue to use only J interpreters which are friendly to wicked entities
> to perform critical tasks.
>
> > > (An issue, here, is that J currently doesn't provide operations to
> > > build such structures,
>
> That is in theory, in practice the official interpreters still do.
> Granted, each new release makes it increasingly difficult (that is,
> unfriendly to wicked entities).
>
> > > and verifying the correctness of the
> > > abstraction leaks becomes a whole new issue when we also demand a
> > > correct and robust system.)
>
> Do you know of any actual issue, from a language perspective, associated
> with lifting the restrictions which demand that verbs can only produce and
> take nouns, and adverbs and conjunctions can only take verbs or nouns?
>
> One major reason to use wicked entities is that it greatly facilitates
> tacit meta-programming, verbs are capable to produce dynamically any kind
> of word, including verbs. A component of the system automatically produces
> and searches constantly, weekends are not excluded, for suitable variants
> of trading algorithms (that is, verbs, complex tacit fixed verbs); this
> component is particularly valuable during turbulent periods.
>
> I have never heard of any compelling reason to forbid the wicked way. Who
> knows? Maybe there is one... Yet, it works (and would not be betting
> without it).
>
>
>
> On Fri, Mar 6, 2020 at 12:33 PM Raul Miller <rauldmil...@gmail.com> wrote:
> >
> > On Fri, Mar 6, 2020 at 12:09 PM Jose Mario Quintana
> > <jose.mario.quint...@gmail.com> wrote:
> > > The short answer is: I would like, at least, to change whatever needs
> to be
> > > changed in the interpreter to produce and display proper linear
> > > representations (LRs) of adverbs which currently have faulty ones, and
> > > change what needs to be changed in the documentation to legitimize the
> past
> > > (and current?) behavior of tie (`), train (`:6), and agenda (@.) by
> > > removing needless restrictions, or at least preserve the behavior.
> >
> > Note that getting useful linear representations from 5!:5 becomes
> > significantly harder if it must also represent nouns which contain
> > non-nouns.
> >
> > (An issue, here, is that J currently doesn't provide operations to
> > build such structures, and verifying the correctness of the
> > abstraction leaks becomes a whole new issue when we also demand a
> > correct and robust system.)
> >
> > A "simple" solution, here, might be to extend J with something like `
> > which takes an atomic representation for its left argument and builds
> > a gerund (or maybe "gerund" -- we might also need to sort out our
> > terminology) whose left-most element is the value represented by that
> > atomic representation. (And, deals with the memory management issues
> > and domain issues which result.) But even this level of "simple" might
> > be above the level of complexity for j901 bugfixes. (And need some
> > supporting use cases -- practical examples where this is not just
> > possible but also is clearly the right approach.) (And, I don't know
> > if this (`) analog would be a primitive or a foreign...)
> >
> > So, for J901 at least, I think it makes sense to restrict focus to
> > getting 5!:5 to represent the things that J901 represents. (I already
> > have problems keeping up with all the details that Henry has been
> > working with.)
> >
> > I suspect my point of view is disappointing to you, but I am hoping
> > you can at least understand where I'm coming from...
> >
> > Thanks,
> >
> > --
> > Raul
> > ----------------------------------------------------------------------
> > 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
