Parsing overhead being negligible or not depends on the associated computational work.
If the computations are trivial, parsing overhead gains relative significance. If the code is executed many times, that significance is amplified. (Which is exactly what's happening in the example you've shown here.) But if the computations require significant time, or if they're only used a few times, I think that parsing overhead would indeed be negligible. Anyways... pulling parsing out of inner loops and/or eliminating those loops tends to be a Really Good Idea. (Which you know already. But maybe it doesn't hurt too much to emphasize this.) Thanks, -- Raul On Wed, Sep 29, 2021 at 3:30 PM Henry Rich <[email protected]> wrote: > > No, parsing overhead for explicits is NOT negligible. Consider the > definition > > 3 : 0 ] 1e6 > total =. 0 > for. i. y do. > total =. (>: {{ u }})total > end. > total > ) > > When the definition is first encountered, {{ u }} is turned into (1 : > 'u'). But then, every time the sentence is encountered, the (1 : 'u') > is executed: this means scanning the string, breaking it into sentences, > calculating the size of the symbol table, and initializing it. Then the > explicit adverb is executed: arguments are assigned, the execution loop > is set up & processed. > > To see the difference, replace {{ u }} with the equivalent ]: in the > definition above. > > Henry Rich > > On 9/29/2021 2:10 PM, 'Pascal Jasmin' via Beta wrote: > > tacit forks are available. where X is a supplied parameter > > > > u x x -> ]: x x or [. x x > > u v x -> [. ]. x > > x x uCv -> VVC > > > > a template for generic adverb that returns conjunction > > > > quoteifnot =: quote^:('''' ~: {.) > > lrA =: 1 : '5!:5 < ''u''' > > lrAs =: 1 : 'if. 0 = 4!:0 <''u'' do. if. 2 = 3!:0 u do. u else. u lrA end. > > else. u lrA end.' > > > > > > AF =: 1 : ' 2 : ('' (u '', u lrAs , '' v)'') ' > > > > > > +/ % AF # > > +/ % # > > > > but also permits conjunctions (while silly in this case. Another thread > > (FC definition) can use that flexibility) > > > > +/ '@' AF # > > > > +/@# > > > > Producing tacit results has the advantage of ambivalence and generally > > quicker execution. Using explicit modifiers to do so is just minor parsing > > overhead when x y are not used, and no "real" computations are performed. > > The parsing overhead just applies to the formation of the tacit expression, > > and is truly negligible. > > > > > > On Tuesday, September 28, 2021, 11:51:00 p.m. EDT, Elijah Stone > > <[email protected]> wrote: > > > > > > > > > > > > A tacit modifier cannot currently produce a fork as an arbitrary function > > of its operands. (This is not the same thing as _implementing_ fork > > tacitly. The modifier is still only a verb-producing adverb or > > conjunction, but the resulting verb is a fork.) > > > > AAV is closest thing currently, but its right tine is fixed, and the left > > two cannot combine their operands with each other; so it must be nested > > and combined with other trains; an exercise in verbosity and obfuscation. > > > > Let me be more concrete. Given C0 C1 C2, I would like to be able to write > > tacitly {{ (u C0 v) (u C1 v) (u C2 v) }}. (And the analogous adverbial > > form, though that is obviously less important.) > > > > In a 20-year-old thread referenced by Henry, Roger Hui says that forks and > > atops are fundamental. But this is not quite right. f g h can be reduced > > to [ (f g ]) h. Fork augments its root's left and right arguments > > _separately_, which suggests a way out: fork is actually a combination of > > two conjunctions (call them left fork and right fork). If they are > > written [.. and ].., then f g h is simply shorthand for f ].. g [.. h. > > Then my above conjunction becomes simple, pretty, and obvious: > > > > C0 ].. C1 [.. C2 > > > > I think it generalises well. Hook is simply [. [.. (@]). > > Compose is ]. ].. [. [.. ].--a bit noisy, but clear enough. > > > > (Of course, it's not all sunshine and roses. For consistency with the > > mistakes of @, &, and &., ].. and [.. should take on the relevant parts > > of the augmenting verb's rank, with ]..: and [..: as infinitely-ranked > > counterparts. But perhaps we can skip that this time? :) > > > > -E > > > > P.S. I will also note an incidental argument in favour of conjunctive > > hooks. If h is the 'hook' conjunction then, as V0 V1 is shorthand > > for V0 h V1, so is C0 C1 shorthand for C0 h C1. This remains > > relevant even if h is redefined to be saner. > > > > P.P.S. Also nice would be a higher-order constant function. A constant > > verb can be written as m"_; and a constant adverb as (a[.) or > > (].a). A constant conjunction must be a[.junk or junk].a, where > > junk is a useless conjunction or adverb. > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > -- > 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
