Tacit J sometimes has a performance advantage over explicit J. Explicit J sometimes has a performance advantage over tacit J.
That said, I find both useful as tools for my own thinking. They offer ways of expressing concepts and ways of experimenting with them. They are not my only tools, but I would not want them to be. Personally, I do not think of them as puzzles, though I suppose any mathematical structure could be thought of that way. As for having "things you need in a program explicitly shown" - that can be good argument for concise expressions, so that you can see more of what you are working on at one time. (On the other hand, some people would argue the opposite. Different people have different approaches, different focusses and different perspectives.) That said, I think you might want to spend more time understanding how J's grammar works. It's really quite simple - far simpler than the parser you have proposed as a partial replacement. Thanks, -- Raul On Sat, Sep 30, 2017 at 7:23 PM, Erling Hellenäs <[email protected]> wrote: > Hi all ! > > I'll try to summarize this thread so far. > > Explicit and tacit J can be used interchangeably for everything you can do > in J. > Tacit J has a slight performance advantage. This can be useful in > time-critical applications or time-critical parts of applications. > Tacit J does not have mutable variables. Writing the code in tacit J could > therefore improve testability and lower the amount of bugs. > For most applications Henry's proposal of simplified explicit definitions > and my proposal of an addition of tacit verbs with a syntax similar to the > syntax in Henry's proposal would be equivalent. > Because tacit J is somewhat more advanced it would be possible to improve it > further, for example with definitions of adverbs and conjunctions. Another > design choice could be to let it become a more full-fledged functional > language with verbs as primary citizens and the passing of verbs in nouns at > runtime or possibly even having verb results in runtime. Non-mutable > variables could be added to make it more like a full fledged functional > language. > A sequence of monadic verbs in tacit J is normally written f@:g@:h@:i@:] or > something similar. Earlier this syntax had a performance penalty and you'd > have to write it (f@:(g@:(h@:(i@:] )))). This performance problem is now > fixed. Still many find it tedious to write like this, there are different > proposals about how to solve this problem and there is a patch to J, Jx, > with solutions. There are also small utilities to generate the sequences and > there are small compilers from explicit J syntax to tacit J syntax. > Another perceived problem is that a conjunction ties to only the first verb > to it's right. It does not tie to combinations of verbs, adverbs and > conjunctions to the right forming a verb. This means that sometimes you have > to enclose such combinations in brackets. There is a fix for this in a patch > to J, Jpp. The fix probably only concerns the different "composition" > conjunctions. > I stated some things I feel are problems with the tacit J syntax: > -Trains are interpreted very differently depending on if it is a hook or > fork. This means that you have to count the number of verbs to be able to > understand it. My personal opinion is that this is "difficult" in the sense > that you can't just start reading the logic. You have to pre-compile the > train in your head, find the verbs, count them and then start understanding > the logic. > -I often start a problem solution from explicit J and then move it to tacit > J. I feel that it is tedious to have to rewrite it. I would prefer if the > basic syntax was the same. > -If you want to optimize the code in tacit J it is written differently > depending on if it is in a monadic or dyadic context. If you then add or > remove an argument you'll have to rewrite the code. I would prefer to not > have to think about this. My choice is normally to not optimize the code, to > write the code so that it is interpreted the same in a monadic as in a > dyadic context. > -I tried once to create a table from combinations of two and three > consecutive verbs to the best way to write it in tacit J. I think I managed > once, but it was lots of combinations. I lost the paper and tried to do it > again, but it is still not finished. I got stuck at the time and gave it up. > I might try to continue from where I stopped. I think it is too complex to > leave to the reader to understand this routing without explicit hints. I > also think it is hard to find the optimal routing scheme when you write > tacit j code. > -When you add or remove verbs this optimal routing scheme seems to change > and you have to do other changes to your code to make it work or make it > optimal. > -It is some kind of puzzle with many variables. Which argument should be > routed to which verb, which rank the verb you route from has and which > target rank you have for the result of each routing operator. Then there is > a question of verbs and their inverse. There is something you want to do but > the piece of the puzzle you need seems most often to be missing. I prefer to > just jot down what I have in my head, even if it means some more keypresses. > I have a problem to solve, a work to do. I don't want to have to think about > lots of irrelevant detail. > -I admit that it can be fun as some kind of soduku. That finding the > solutions with the minimum number of keypresses can be fun. That you can > learn from the process. That currying can help you find the optimal > solution. > I think I know, from my experience with other people and from theoretical > studies in cognition, that few if any people can handle this kind of > complexity in a good way. Even the most clever people have very limited > mental abilities and are reliant on good strategies to do complex work. One > such strategy is to keep things in view. Out of sight, out of mind. Creative > people fill the floor and the walls in the room with everything related to > what they are doing. So, it is important that things you need to understand > in a program is explicitly shown, that it is in sight. > Well, to round off this post, I think that to make tacit J work as a > notation, as a tool of thought, you'll have to implement the addition I > propose. > > I will stop participating in this thread. When discussion ends, I'll move my > proposal to proposals. > > Cheers, > Erling Hellenäs > > > > > > > > > On 2017-09-30 21:38, Erling Hellenäs wrote: >> >> So, tacit code creates composites of compiled code and explicit code is >> still interpreted each time it is called? >> There is nothing like a J JIT compiler? /Erling >> >> 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
