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
