oops sorry - should have said www.learningj.com/W0.zip On Sep 29, 2017 11:37 AM, "roger stokes" <[email protected]> wrote:
> J with the original parsing rules which Henry and Bill mention is still > available today. > > For Windows, www.learning.com/W0.zip > > For Linux, www.learningj.com/L0.zip > > These are recompilations (by me) of the source files released by ISI in > about 1993, > documented in Roger Hui's "An Implementation of J". > Each includes standalone executable J interpreter, read.me file, source > files > and build script. > > A 1993 Dictionary (photographed inexpertly by me from a paper copy) > is at www.learningj.com/JDOC1993.zip . It is 46 Mb of jpegs. > > Regards > > > > > On Fri, Sep 29, 2017 at 3:58 AM, 'Jon Hough' via Programming < > [email protected]> wrote: > >> >Note for those who have not been using J for >> >more than 10 years: the >> >original tacit >> >language allowed trains that produced modifiers. >> >> What is the latest J version that had this? Is it available somewhere? >> >> -------------------------------------------- >> On Fri, 9/29/17, Henry Rich <[email protected]> wrote: >> >> Subject: Re: [Jprogramming] Tacit Expressions with Explicit J Syntax >> To: [email protected] >> Date: Friday, September 29, 2017, 11:45 AM >> >> 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). >> >> 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/forum >> s.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
