Thanks for those historical pointers to J implementation, Jose. Quite right: my remarks about generating a "better" language processor using an implementation in the target language strictly applied to compilers. To extend this notion to interpreters and achieve significant performance benefit you'd have to use the in-J implementation -- not to add another layer to J interpretation at runtime -- but to generate a new interpreter (or its table of calls to semantic fns, if this is identifiable as a component).
FORTH emulators (FORTH interpreters implemented in FORTH) were notably used to assemble interpreters for novel target machines. I say "assemble" because arguably FORTH was nothing but a glorified macro-processor, outputting branch instructions to the entry-points of "word" subroutines (the FORTH language, like J, consisted of "words").Fortunately the "p-code interpreter" (by which I mean the routine that ran tokenized words in succession) was so fast and simple that there was little practical benefit in generating machine code as opposed to p-code. It was sufficient to machine-code by-hand a small kernel of words. This set was well-recognised: in fact they even built a FORTH microprocessor (the NC4000 chip), whose instruction set was this kernel. It was described in a monograph. by C H Ting called "Footsteps in an empty valley". http://www.ultratechnology.com/offete.html Incidentally, machine-code implementation was an option at any stage for any word. So a capacity for speed-ups and fast idioms came free. Emulation could identify bottlenecks, and hence words worth speeding-up as a matter of priority. It will be a long time before I contemplate generating C source (again). My idea was a lot humbler: to have a model emulator to experiment with language features, for which performance doesn't matter. That is to say, not real-world performance. However an emulator, once built, proves its worth in lots of unanticipated ways. Especially if the entire set of semantic fns can be easily unbolted and replaced with a new set. Then generating p-code, or even C source, might become an option. Ian On 7/26/09, Jose Mario Quintana <[email protected]> wrote: > You might also be interested in an old thread > http://www.jsoftware.com/pipermail/general/2001-November/008262.html > and > http://www.jsoftware.com/pipermail/general/2001-December/008595.html > You should be able to imply the tree type description for an early version > of J from the source of its implementation: > http://www.math.uwaterloo.ca/apl_archives/j/early_j/src/j7/ (J source > including LinkJ) and this task would be a lot easier if you could get a copy > of the “An Implementation of J” (1992) yellow spiral bounded booklet. > An alternative to a write a J interpreter in J could be to write a J program > that generates a J interpreter; for example, a J program that writes (and > compiles) the source of a J interpreter in C. Then, of course, it would be > possible to at least match the performance of the current J interpreter. > Would not be neat to write a description of J in J as input for a J program > that generates a J interpreter from that description (see > http://www.jsoftware.com/pipermail/programming/2009-July/015481.html for a > hint)? That is easy for me to say since I have not compiled for decades a > program written in a familiar programming language. > > > > ________________________________ > From: Ian Clark <[email protected]> > > To: Programming forum <[email protected]> > > Sent: Saturday, July 25, 2009 4:05:33 PM > > Subject: Re: [Jprogramming] Reimplementing J > > > > Can I play too? I've been meaning to do this for years, but I never got up > > the initiative. If you start the project I'm happy > > Delighted to have a co-worker (=player). Will keep you up-to-date. > Thanks for the leads. > > Itching to get started. Must get APWJ Edn 2 tested & released first, > though. Irresponsible to get sidetracked. > > Ian > > > On 7/25/09, Dan Bron <[email protected]> wrote: > > > Does Dan's list have any official standing? > > > > > > Nope. BTW, I am not the only contributor to the list: Oleg and others > have added definitions as well. (Some without knowing it, > > as I steal their Forum code and post it there.) > > > > PrimitivePrimitives is really just a fun side-project. As a symptom of > that, you'll notice that many primitives are missing, even > > those with trivial implementations. Further, you'll notice many > reimplementations have limited domains. This is because I really > > focus on the "interesting" or "fun" relationships between primitives. > > > > > > > building myself a working J emulator > > > > > > Can I play too? I've been meaning to do this for years, but I never got > up the initiative. If you start the project I'm happy > > (enthused) to help. > > > > Note that you'd have to start at a lower level than primitive definition. > But you can steal "word formation" (lexing) from the > > specificiation of monad ;: and you can steal parsing from open'trace' > . > > > > There's plenty of other goodies you might find helpful, e.g. > http://www.jsoftware.com/jwiki/Essays/Rank and > > http://www.jsoftware.com/jwiki/Guides/Parsing . > > > > -Dan > > > > > > PS: I got a kick out of it when you said: > > > > > being implemented in more primitive primitives > > > > > > in http://www.jsoftware.com/pipermail/programming/2009-July/015493.html > > > > > > ---------------------------------------------------------------------- > > 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
