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/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
