Quick request as we're nearing 100 messages: How about splitting out questions about $: etc. into a new thread? I think it might be easier for everyone to follow.
/M On Sat, Sep 30, 2017 at 1:35 PM, Erling Hellenäs <[email protected]> wrote: > Hi all ! > > Is there a way to get $: to work with agenda and with explicit code? > > f=: 4 : 'x (4 : ''x'')`(4 : ''s,y +{: s=.x f <: y'')@.(4 :''x < y'') y' > 4 f 8 > 4 9 15 22 30 > f=: 4 : 'x (4 : ''x'')`(4 : ''s,y +{: s=.x $: <: y'')@.(4 :''x < y'') y' > 4 f 8 > |stack error: f > | s,y+{:s=.x $:<:y > > I guess $: refers to the unnamed verb directly containing it? But this means > it does not work with explicit code in agenda? > > Interesting feature of fix: > > f=: [`(] (] , [ + [: {: ]) [ f [: <: ])@.(<) > f=: f f. > f > [`(] (] , [ + [: {: ]) [ f [: <: ])@.< > 4 f 8 > 4 9 15 22 30 > > Cheers, > Erling > > > > > > On 2017-09-30 21:48, Henry Rich wrote: >> >> On 9/30/2017 3:38 PM, Erling Hellenäs wrote: >>> >>> So, tacit code creates composites of compiled code and explicit code is >>> still interpreted each time it is called? >> >> Broadly, that's right. But remember that interpretation embraces parsing >> and bookkeeping. Tacit code still has the bookkeeping. >>> >>> There is nothing like a J JIT compiler? /Erling >> >> No, because the bookkeeping would remain. >> >> Henry Rich >> >>> >>> On 2017-09-30 21:22, Erling Hellenäs wrote: >>>> >>>> Hi all! >>>> >>>> OK. Yes. Considering this the differences seem very small. Long ago I >>>> remember looping programs I made 270 times faster by removing the loop and >>>> using some recursive tricks. Now the looping solution can often even be >>>> faster. >>>> >>>> No one want's to answer the question if explicit code can replace tacit >>>> code everywhere? $: did not seem to work in explicit code, but there is >>>> also >>>> no need for it there. >>>> >>>> I recognized you can even use explicit code in tacit. That's mean. >>>> Global variables and all. Mutable state. >>>> >>>> a=: 0.01 >>>> (+/ (4 :'x % y+a') #) 1 2 3 >>>> 1.99336 >>>> >>>> Cheers, >>>> Erling >>>> >>>> On 2017-09-30 19:20, Henry Rich wrote: >>>>> >>>>> Bill hit the nail on the head: >>>>> >>>>> > IMO it doesn't matter whether to use tacit or explicit, >>>>> > the more important thing is to understand how J works. >>>>> >>>>> u@:v y means 'Do v on y; then do u on that result'. It is exactly the >>>>> same as >>>>> (u v y). >>>>> >>>>> u@v y means 'Do v on the first cell of y; then do v on that; repeat >>>>> for all cells' >>>>> If there are many cells in y, you will be repeating the overhead of >>>>> starting v and then u. >>>>> >>>>> What is that overhead? In your examples using @, (1) parsing and (2) >>>>> bookkeeping. >>>>> Parsing: (3 :'-y')@- v is slow partly because every sentence of an >>>>> explicit entity is parsed anew when the sentence is executed. Thus the >>>>> sentence '- y' is parsed repeatedly. In >>>>> -@- y the verb, -@-, is parsed once. >>>>> >>>>> Bookkeeping: every J noun can be an array with any type. Every time you >>>>> start a verb, each argument must be analyzed. >>>>> (3 :'-y')@- v starts 3 verbs for each cell: -, (3 :'-y'), and - again. >>>>> The - starts are quick, because they follow an optimized path for >>>>> arithmetic >>>>> on singletons. (3 :'-y') is another story: starting an explicit definition >>>>> means getting ready for control structures, creating a namespace, >>>>> initializing the names xymnuv, and a bit more. That's where most of the >>>>> time is being spent. >>>>> -@- starts just the 2 verbs - and -, each of which is fast. >>>>> >>>>> There are other overheads to the explicit form: (1) executing -y >>>>> requires looking up the name y (2) assigning the result of - to the name y >>>>> means that -y cannot be executed in-place, which is slower. >>>>> >>>>> Finally, there is an overhead for splitting v into cells and assembling >>>>> the cell-results into a single array. This is small. >>>>> >>>>> When you write u@:v, you have only 3 verbs to start: (u@:v), v, and u. >>>>> If u is explicit, you have the extra explicit overhead just once. If you >>>>> ran a test using @: on long v, I would expect the tacit code to take less >>>>> memory and time mostly because -@:- executes the first - in-place while >>>>> 3 : '-y'@:- doesn't. >>>>> >>>>> >>>>> Henry Rich >>>>> >>>>> >>>>> On 9/30/2017 10:24 AM, Erling Hellenäs wrote: >>>>>> >>>>>> Hi all! >>>>>> >>>>>> Yes, well, I wanted to measure differences between tacit and explicit >>>>>> expressions as such, so I tried to avoid unrelated processing time. In >>>>>> case >>>>>> you have significant operations, these differences disappear, of course, >>>>>> and >>>>>> the processing time in these operations dominate over interpretation >>>>>> time or >>>>>> small differences in the code generated. >>>>>> It seems better to create an internal loop then to have ts loop a big >>>>>> number of times over a very small load, since the measurement process as >>>>>> such might dominate in the latter case. >>>>>> The way you measure, you have to set v low and n high to avoid >>>>>> processing time, and it seems you didn't. >>>>>> I understand that these differences might not be important in >>>>>> practice. Thanks for your judgement on that. >>>>>> Any other opinions about performance differences between tacit and >>>>>> explicit code? Are there any cases when they are big? >>>>>> >>>>>> ts=: 6!:2 , 7!:2@] NB. Time and space >>>>>> v=.1 >>>>>> n=.5000000 >>>>>> n ts'(3 :''-y'')@:- v' >>>>>> 3.03253e_6 6784 >>>>>> n ts'(-)@:- v' >>>>>> 4.83682e_7 1152 >>>>>> v=.?~n >>>>>> ts'(3 :''-y'')@- v' >>>>>> 1.8912 1.34712e9 >>>>>> ts'(-)@- v' >>>>>> 0.93178 1.34711e9 >>>>>> >>>>>> Cheers, >>>>>> Erling >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2017-09-30 13:13, bill lam wrote: >>>>>>> >>>>>>> Since the time taking is small, better to run n times >>>>>>> to obtain an average. >>>>>>> >>>>>>> + and - are scalar functions of rank-0, but J has >>>>>>> integrated rank support so that there will be no >>>>>>> performance penalty if its arguments are arrays. >>>>>>> >>>>>>> @ will inherent the rank of - , better to use @: in >>>>>>> this case. >>>>>>> >>>>>>> 50 ts'(3 :''-y'')@- v' >>>>>>> 0.183617 8.39565e6 >>>>>>> 50 ts't@- v' >>>>>>> 0.105698 8.3904e6 >>>>>>> >>>>>>> 50 ts'(3 :''-y'')@:- v' >>>>>>> 0.00245378 1.67837e7 >>>>>>> 50 ts't@:- v' >>>>>>> 0.00206336 8.39002e6 >>>>>>> >>>>>>> IMO it doesn't matter whether to use tacit or explicit, >>>>>>> the more important thing is to understand how J works. >>>>>>> >>>>>>> >>>>>>> Сб, 30 сен 2017, Erling Hellenäs написал(а): >>>>>>>> >>>>>>>> Hi all ! >>>>>>>> >>>>>>>> Can tacit and explicit J be interchangeably used everywhere ? >>>>>>>> >>>>>>>> Examples of use: >>>>>>>> >>>>>>>> 4 (3 :'- y')@:(4 :'x + y') 5 >>>>>>>> _9 >>>>>>>> 3(4 :'(1: x + y)#''x'' ')`(4 :'(1: x + y)#''y'' ')@.(4 :'x < >>>>>>>> y')4 >>>>>>>> y >>>>>>>> >>>>>>>> What are the performance implications of using explicit J instead of >>>>>>>> tacit >>>>>>>> J? >>>>>>>> >>>>>>>> This little example indicates that tacit J is about twice as fast? >>>>>>>> >>>>>>>> v=.?~1000000 >>>>>>>> 10{.v >>>>>>>> 733026 963097 739111 754321 510732 704647 209066 833891 281909 >>>>>>>> 851842 >>>>>>>> #v >>>>>>>> 1000000 >>>>>>>> t=: - >>>>>>>> e=: 3 :'-y' >>>>>>>> ts't@- v' >>>>>>>> 0.49503 2.6439e8 >>>>>>>> ts'e@- v' >>>>>>>> 0.743922 2.6439e8 >>>>>>>> ts'(3 :''-y'')@- v' >>>>>>>> 0.38011 2.64395e8 >>>>>>>> ts'(-)@- v' >>>>>>>> 0.186993 2.6439e8 >>>>>>>> ts'-@- v' >>>>>>>> 0.182542 2.6439e8 >>>>>>>> ts'(3 :''- <: >: y'')@- v' >>>>>>>> 0.465578 2.64395e8 >>>>>>>> ts'([: - [: <: [: >: ])@- v' >>>>>>>> 0.25002 2.64391e8 >>>>>>>> *./ (t@- v) = v >>>>>>>> 1 >>>>>>>> *./ (e@- v) = v >>>>>>>> 1 >>>>>>>> *./ ((3 :'-y')@- v) = v >>>>>>>> 1 >>>>>>>> *./ ((-)@- v) = v >>>>>>>> 1 >>>>>>>> *./ (-@- v) = v >>>>>>>> 1 >>>>>>>> *./ ((3 :'- <: >: y')@- v) = v >>>>>>>> 1 >>>>>>>> *./ (([: - [: <: [: >: ])@- v) = v >>>>>>>> 1 >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Erling >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2017-09-29 20:10, Erling Hellenäs wrote: >>>>>>>>> >>>>>>>>> An additional comment. see below. /Erling >>>>>>>>> >>>>>>>>> On 2017-09-29 04:45, Henry Rich wrote: >>>>>>>>>> >>>>>>>>>> Taking your last sentence first, you would have to supply some >>>>>>>>>> evidence to make me believe that tacit forms have any intrinsic >>>>>>>>>> performance penalty. >>>>>>>>>> >>>>>>>>>> It is dawning on me that you want fast function definition, but >>>>>>>>>> that >>>>>>>>>> you want it to produce tacit code. You find the current tacit >>>>>>>>>> language difficult, and you propose to replace it with something >>>>>>>>>> that looks more like the explicit language. That seems like a >>>>>>>>>> mistake to me, because: >>>>>>>>>> >>>>>>>>>> 1. Most of the responders on this Forum don't agree with you that >>>>>>>>>> the tacit language is opaque >>>>>>>>>> >>>>>>>>>> 2. Even with a fast function definition, many J programmers (I >>>>>>>>>> dare >>>>>>>>>> not say all J programmers with a soul) will always prefer (+ i.) >>>>>>>>>> to >>>>>>>>>> (. x + i. y). >>>>>>>>> >>>>>>>>> This is a strange comparison, (+ i.) is comparable to + i. with >>>>>>>>> explicit >>>>>>>>> syntax. [ ( + i. ) ] is comparable to x + i. y and ([ (+ i.) ]) is >>>>>>>>> comparable to (. x + i. y). >>>>>>>>>> >>>>>>>>>> 3. Tacit code is a different mindset from explicit code. It's >>>>>>>>>> functional. It doesn't have assignments or control words >>>>>>>>>> >>>>>>>>>> 4. Operands to modifiers cannot be arguments to tacit code >>>>>>>>>> >>>>>>>>>> 5. Explicit syntax is an improvement in some cases, not all. +/ >>>>>>>>>> *: >>>>>>>>>> y is a little lighter than +/@:* y but (+/ y) % #y is heavier than >>>>>>>>>> (+/ % #) y >>>>>>>>>> >>>>>>>>>> 6. So: even if I were redesigning the language from scratch, I >>>>>>>>>> wouldn't represent tacit forms your way. I would, as Roger has >>>>>>>>>> observed, switch the meanings of (u v) and (u@:v), but I would >>>>>>>>>> keep >>>>>>>>>> the rest as is. >>>>>>>>>> >>>>>>>>>> [Note for those who have not been using J for more than 10 years: >>>>>>>>>> the original tacit language allowed trains that produced >>>>>>>>>> modifiers. >>>>>>>>>> That was, to me, Ken's finest achievement: a really beautiful >>>>>>>>>> language, immensely supple, even though it had no syntactic >>>>>>>>>> elements >>>>>>>>>> but the primitives and parentheses. I never found it wanting. It >>>>>>>>>> was fully understood by no more than half a dozen people, I think. >>>>>>>>>> It was removed from J because explicit forms could produce the >>>>>>>>>> same >>>>>>>>>> results: a good business decision, but a loss to computer science >>>>>>>>>> and art.] >>>>>>>>>> >>>>>>>>>> 7. The bottom line: tacit forms work pretty well as they are, and >>>>>>>>>> an >>>>>>>>>> incompatible change to them could be justified only by a huge >>>>>>>>>> improvement in readability or efficiency. You haven't shown that. >>>>>>>>>> >>>>>>>>>> Henry Rich >>>>>>>>>> >>>>>>>>>> On 9/28/2017 10:09 PM, Erling Hellenäs wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all ! >>>>>>>>>>> >>>>>>>>>>> Is improving explicit J the way forward? Or is tacit J and >>>>>>>>>>> improving tacit J the way forward? >>>>>>>>>>> I also think that "Henry's" proposal, which is similar to what I >>>>>>>>>>> have been writing about for a long time, is great. It is easy >>>>>>>>>>> to do and have great benefits for people working in explicit J. >>>>>>>>>>> They will not have to type lots of double quotes, or write their >>>>>>>>>>> own J versions with special duplicate quote functionality. >>>>>>>>>>> That doesn't mean that tacit J could not also be improved? >>>>>>>>>>> Henry's proposal is nearly identical to my proposal but mine is >>>>>>>>>>> about tacit J, it is addressing problems with tacit J. His is >>>>>>>>>>> about explicit J. It is addressing problems with explicit J, the >>>>>>>>>>> quote duplication problem. I am addressing problems with tacit >>>>>>>>>>> J, mainly the problem which makes people write cross-compilers >>>>>>>>>>> from explicit to tacit J or programs to automatically pack verb >>>>>>>>>>> sequences in tacit J into their packages of brackets and phony >>>>>>>>>>> "compositors", like this - f@:(g@:(h@:(i@:(j@:])))). People who >>>>>>>>>>> are working professionally with tacit J and who knows that >>>>>>>>>>> cheating and writing tacit J like most other people do will slow >>>>>>>>>>> their programs much too much? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Erling >>>>>>>>>>> >>>>>>>>>>> On 2017-09-29 03:13, Joe Bogner wrote: >>>>>>>>>>>> >>>>>>>>>>>> I also like Henry's suggestion of fast function definition. It's >>>>>>>>>>>> also >>>>>>>>>>>> unclear to me on how the Erling's suggestion improves upon that. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Sep 28, 2017 at 5:45 PM, Louis de Forcrand >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I don't really understand what you wish to add either, Erling. >>>>>>>>>>>>> >>>>>>>>>>>>> If you want to use explicit J syntax, you could write an >>>>>>>>>>>>> explicit verb. >>>>>>>>>>>>> >>>>>>>>>>>>> You write: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Particularly to create what you most commonly need, a sequence >>>>>>>>>>>>>> of >>>>>>>>>>>>>> monadic verbs, each acting on the result of the verb to the >>>>>>>>>>>>>> right. >>>>>>>>>>>>>> Well, it is not complicated as such, but for some >>>>>>>>>>>>>> reason people don't >>>>>>>>>>>>> >>>>>>>>>>>>> like >>>>>>>>>>>>>> >>>>>>>>>>>>>> the obvious way to do it, which is [: f [: g [: h ]. >>>>>>>>>>>>>> Then they dive into >>>>>>>>>>>>> >>>>>>>>>>>>> a >>>>>>>>>>>>>> >>>>>>>>>>>>>> mess of complications. I mean the cap should not be necessary. >>>>>>>>>>>>>> That >>>>>>>>>>>>> >>>>>>>>>>>>> simple >>>>>>>>>>>>>> >>>>>>>>>>>>>> right to left execution should be the default, >>>>>>>>>>>>>> possibly modified with >>>>>>>>>>>>>> parenthesis. That tacit and explicit J should have >>>>>>>>>>>>>> the same basic syntax. >>>>>>>>>>>>> >>>>>>>>>>>>> f@:g@:h? >>>>>>>>>>>>> In addition, I disagree with your last two sentences. >>>>>>>>>>>>> What's the point of >>>>>>>>>>>>> having tacit syntax if it's the same as explicit syntax? If you >>>>>>>>>>>>> want >>>>>>>>>>>>> explicit syntax, write an explicit verb; other times >>>>>>>>>>>>> tacit syntax is really >>>>>>>>>>>>> practical. >>>>>>>>>>>>> In an explicit verb, simple right to left execution *is* the >>>>>>>>>>>>> default. >>>>>>>>>>>>> >>>>>>>>>>>>> In any case I don't really see how the rest of your >>>>>>>>>>>>> suggestion differs >>>>>>>>>>>>> from Henry's (.). verbs, which I like very much by the way. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Louis >>>>>>>>>>>>> >>>>>>>>>>>>>> On 28 Sep 2017, at 14:53, Raul Miller <[email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jose's work is impressive, but I try to avoid it >>>>>>>>>>>>>> because of the extra >>>>>>>>>>>>>> complexity it creates when I want to (for example) >>>>>>>>>>>>>> provide a parameter >>>>>>>>>>>>>> in clauses for conjunctions like &. -- the extra complexity >>>>>>>>>>>>>> can be a >>>>>>>>>>>>>> nice mental exercise and maybe even a cure for boredom, but I >>>>>>>>>>>>>> feel >>>>>>>>>>>>>> that I have the right to treat it as unnecessary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Raul >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Sep 28, 2017 at 8:33 AM, Erling Hellenäs >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all ! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am very impressed by Jose's work and I think it is an >>>>>>>>>>>>>>> excellent >>>>>>>>>>>>>>> illustration to why we need the modification to J I propose. >>>>>>>>>>>>>>> It is extremely complicated to do these things >>>>>>>>>>>>>>> which should be simple, >>>>>>>>>>>>> >>>>>>>>>>>>> as I >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> see it. Particularly to create what you most >>>>>>>>>>>>>>> commonly need, a sequence >>>>>>>>>>>>> >>>>>>>>>>>>> of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> monadic verbs, each acting on the result of the verb to the >>>>>>>>>>>>>>> right. >>>>>>>>>>>>>>> Well, it is not complicated as such, but for >>>>>>>>>>>>>>> some reason people don't >>>>>>>>>>>>> >>>>>>>>>>>>> like >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the obvious way to do it, which is [: f [: g [: h ]. Then >>>>>>>>>>>>>>> they dive >>>>>>>>>>>>> >>>>>>>>>>>>> into a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> mess of complications. I mean the cap should not be >>>>>>>>>>>>>>> necessary. That >>>>>>>>>>>>> >>>>>>>>>>>>> simple >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> right to left execution should be the default, >>>>>>>>>>>>>>> possibly modified with >>>>>>>>>>>>>>> parenthesis. That tacit and explicit J should have the same >>>>>>>>>>>>>>> basic >>>>>>>>>>>>> >>>>>>>>>>>>> syntax. I >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tried my ideas of a different tacit J in a test >>>>>>>>>>>>>>> implementation and it >>>>>>>>>>>>> >>>>>>>>>>>>> was >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> great. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Erling Hellenäs >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2017-09-28 05:29, Jose Mario Quintana wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Erling, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You are right, the adverb (At) produces tacit sentences but >>>>>>>>>>>>>>>> it is >>>>>>>>>>>>> >>>>>>>>>>>>> really >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>> implementation of Dan's pipeline proposal >>>>>>>>>>>>>>>> using strand notation via a >>>>>>>>>>>>>>>> Curried adverb (aka, recurrent adverb and multiple adverb). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, I have written (tacitly) a tacit >>>>>>>>>>>>>>>> Curried adverb (xi) which, >>>>>>>>>>>>> >>>>>>>>>>>>> using >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a lambda-style syntax, produces a tacit verb >>>>>>>>>>>>>>>> which in turn, given its >>>>>>>>>>>>>>>> arguments, produces tacit entities. You >>>>>>>>>>>>>>>> might find xi interesting; the >>>>>>>>>>>>>>>> general form is, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t=. [: v0 v1 ... vn '...' xi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The names v0 v1 ... vn should be >>>>>>>>>>>>>>>> syntactically verbs (recall, xi is a >>>>>>>>>>>>>>>> Curried adverb) but they can represent nouns, verbs, >>>>>>>>>>>>>>>> adverbs, or >>>>>>>>>>>>>>>> conjunctions. I use undefined names since those are >>>>>>>>>>>>>>>> regarded by >>>>>>>>>>>>> >>>>>>>>>>>>> default >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>> verbs (even if xi does not affect in any way >>>>>>>>>>>>>>>> the named verbs). The >>>>>>>>>>>>>>>> literal >>>>>>>>>>>>>>>> '...' represents a quoted J (or more generally a Jx) >>>>>>>>>>>>>>>> sentence. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is how your example can be written using xi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> erase 'b v' >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [: v '([: b ''<:b++/\b-~-.b'' xi >>>>>>>>>>>>>>>> <''\''=v){."0 v' xi <'\\\//\\\//' >>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>> / >>>>>>>>>>>>>>>> / >>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>> / >>>>>>>>>>>>>>>> / >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is the nuisance of quotes within >>>>>>>>>>>>>>>> quotes and the argument must be >>>>>>>>>>>>>>>> boxed; however, this allows, in general, the verb (t) to >>>>>>>>>>>>>>>> produce a >>>>>>>>>>>>> >>>>>>>>>>>>> noun, a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> verb, an adverb, or a conjunction and to >>>>>>>>>>>>>>>> take multiple boxed nouns, >>>>>>>>>>>>> >>>>>>>>>>>>> verbs, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> adverbs, or conjunctions as its argument. >>>>>>>>>>>>>>>> The following verb (t) acts >>>>>>>>>>>>>>>> directly on a couple of (boxed) verbs and produces a verb, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t=. [: u v 'u/@:v' xi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t[:+*:]: NB. Sum of squares >>>>>>>>>>>>>>>> +/@:*: >>>>>>>>>>>>>>>> t[:+*:]: 1 2 3 4 5 >>>>>>>>>>>>>>>> 55 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t[:-%:]: NB. Difference of square roots >>>>>>>>>>>>>>>> -/@:%: >>>>>>>>>>>>>>>> t[:-%:]: 1 2 3 4 5 >>>>>>>>>>>>>>>> 1.55390522 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Note that the Curried higher-order verb (t) >>>>>>>>>>>>>>>> is, in effect, acting on >>>>>>>>>>>>> >>>>>>>>>>>>> two >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> arguments: [:-%:]: and 1 2 3 4 5; >>>>>>>>>>>>>>>> furthermore, t [:-%:]: performs a >>>>>>>>>>>>>>>> partial >>>>>>>>>>>>>>>> application of the verb (t) acting on [:-%:]: . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The following are variations of the verb >>>>>>>>>>>>>>>> produced in [0], the verb (t) >>>>>>>>>>>>>>>> acts on a (boxed) conjunction and produces an adverb, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t=. [: u '(ver adv u)&:train/adv' xi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ]`{.`{:`{: (t [:(<adv@:)]:) NB. Use [:(<'@:')sb in J >>>>>>>>>>>>>>>> ]@:({.@:({:@:{:)) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ]`{.`{:`{: (t [:(<adv@ )]:) NB. Use [:(<'@ ')sb in J >>>>>>>>>>>>>>>> ]@({.@({:@{:)) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ]`{.`{:`{: (t [:(<adv&:)]:) NB. Use [:(<'&:')sb in J >>>>>>>>>>>>>>>> ]&:({.&:({:&:{:)) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> These non-compliant features are not >>>>>>>>>>>>>>>> provided by the Jx interpreter; >>>>>>>>>>>>> >>>>>>>>>>>>> they >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> are, in fact, inherited from the J >>>>>>>>>>>>>>>> interpreter, the Jx facilities just >>>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>> them a lot more accessible. Actually, I have written a >>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>> (admittedly >>>>>>>>>>>>>>>> cumbersome) of xi in J; see [1] for a link >>>>>>>>>>>>>>>> to a zip archive and the >>>>>>>>>>>>> >>>>>>>>>>>>> path >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> a script where xi is defined. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PS. >>>>>>>>>>>>>>>> erase'u0 u1 u2' >>>>>>>>>>>>>>>> 1 1 1 >>>>>>>>>>>>>>>> [: u0 u1 u2 'u0 + u1 + u2' xi 1 ; 2 ; 3 >>>>>>>>>>>>>>>> 6 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> erase'α β γ' >>>>>>>>>>>>>>>> 1 1 1 >>>>>>>>>>>>>>>> [: u0 u1 u2 'u0 + u1 + u2' xi [:α β γ]: >>>>>>>>>>>>>>>> α + β + γ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> References >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [0] [Jprogramming] Gerund composed application >>>>>>>>>>>>>>>> http://www.jsoftware.com/pipermail/programming/2017- >>>>>>>>>>>>>>>> September/048797.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] J Wicked Toolkit >>>>>>>>>>>>>>>> http://www.2bestsystems.com/foundation/j/Jx.zip >>>>>>>>>>>>>>>> \Jx\J\J Wicked Toolkit.ijs >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Sep 27, 2017 at 5:10 AM, Erling Hellenäs >>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi all ! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Pascal, I will come back to your post later. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here is a little compiler written in Jx >>>>>>>>>>>>>>>>> and compiling, as I understand >>>>>>>>>>>>>>>>> it, >>>>>>>>>>>>>>>>> tacit code with explicit J syntax into >>>>>>>>>>>>>>>>> tacit J. I did not test it, I >>>>>>>>>>>>> >>>>>>>>>>>>> just >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> read the post. >>>>>>>>>>>>>>>>> http://www.jsoftware.com/pipermail/programming/2017- >>>>>>>>>>>>> >>>>>>>>>>>>> August/048143.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The code snippet Farey is an example of >>>>>>>>>>>>>>>>> the source code of the little >>>>>>>>>>>>>>>>> compiler. >>>>>>>>>>>>>>>>> I just think we should not have to use a tacit J compiler >>>>>>>>>>>>>>>>> from >>>>>>>>>>>>> >>>>>>>>>>>>> explicit J >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> to be able to use explicit J syntax and >>>>>>>>>>>>>>>>> get a tacit result, a single >>>>>>>>>>>>>>>>> verb. >>>>>>>>>>>>>>>>> It would obviously be better to use >>>>>>>>>>>>>>>>> explicit J syntax in the first >>>>>>>>>>>>>>>>> place, >>>>>>>>>>>>>>>>> as i see it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Erling >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>>> ---------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> This email has been checked for viruses by AVG. >>>>>>>>>> http://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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> 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 >>> >>> >>> >>> ---------------------------------------------------------------------- >>> 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
