Ah, never mind, I see that you do include the sources in with the binaries. That's good enough.
Thanks, -- Raul On Fri, Sep 29, 2017 at 10:49 AM, roger stokes <[email protected]> wrote: > Raul: Can't I'm afraid. All I have to offer are these sources after > editing to avoid compilation errors with the various compilers available at > the time. This was many years ago and originals are long gone. > > On Sep 29, 2017 2:13 PM, "Raul Miller" <[email protected]> wrote: > >> 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
