Can you point at those source files themselves (for the benefit of people not using windows nor linux)?
Thanks, -- Raul On Fri, Sep 29, 2017 at 7:44 AM, roger stokes <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
