Most people when they heard about this assumed the Algol compiler had to be bootstrapped like FORTH: advanced primitives [sic!] being implemented in more primitive primitives. But there's nothing to stop it being the other way round, eg: + being (part) implemented using +/ (say for some of the fancier number types) whilst +/ continues to be implemented using + . There need be no hierarchy of implementation dependency. Unlike FORTH, J is not being used to build itself at runtime, but at some earlier occasion. Think of a lathe being used to turn a replacement screw for itself.
> Would a J interpreter implemented in J outperform the original? (I doubt it, > but....) Maybe not initially, but it would after judicious choice of primitives, _or idioms_, to reimplement. I argue as follows: unless a given J interpreter is optimal, it is possible to write one which executes faster. Then there's nothing to stop the the algorithm to achieve this being written in J. NB: writing a J interpreter in J wouldn't be quite as simple as Roger suggests with: slashdot=: 1 : '=...@[ u...@# ]'. You'd need some sort of engine (maybe written in J, maybe not) to apply JWords (;:) to the code string to be interpreted (presumably containing /.) and there's be a line somewhere looking like this: case. '/.' do. (EQ @ATOP @LEFT @YOU @ATOP @TALLY @RIGHT) pushdown_stack ...to call the semantic fns EQ, ATOP, etc. Though to be sensible, that expression in parentheses wouldn't be handwritten but be generated from Roger's expression: slashdot=: 1 : '=...@[ u...@# ]' ...retrieved from a primitives definitions script which had been written and debugged using J. Nobody said the J-generator must be single-pass :-) Compiler writers have it easier, because compilers only have to generate p-code. And the Burroughs people had a flying start because the B5500 was a stack-based machine, most ALGOL primitives having a counterpart in the instruction set... so it was nearly p-code already. Ian On Wed, Jul 22, 2009 at 10:11 PM, Jose Mario Quintana<[email protected]> wrote: > I heard the same story as well: they coded their first ALGOL compiler in > ALGOL; then they compiled it by hand and not only the first program that this > object program compiled was its own source but they said that the resulting > object program outperformed the version compiled by hand (if you know what I > mean)! > Would a J interpreter implemented in J outperform the original? (I doubt it, > but....) > > > > > ________________________________ > From: Ian Clark <[email protected]> > To: Programming forum <[email protected]> > Sent: Wednesday, July 22, 2009 4:33:40 PM > Subject: Re: [Jprogramming] Reimplementing J > > Years ago I recall Burroughs staff telling me that the Algol compiler > was itself implemented definitively in Algol -- not just as a > research tool but operationally, to implement all future releases. > > On my protesting what a crazy thing to do, they assured me it wasn't > as chicken-and-egg as it sounds. You only had to get one working > compiler right at the outset and it can be used to generate a more > advanced compiler, and so on. I recall my history teacher telling me > that the industrial revolution was founded on the fact that a lathe > could be used to turn the screw to make a closer-tolerance lathe ... > and so on. > > In practice it was one of the most useful "development tools" the > Burroughs people had, because they could bootstrap up new features, > port to new architectures or better implementations of primitives, and > gave several examples where this had paid off handsomely. Also from a > staffing point-of-view you don't have to employ specialists in the > "implementation language" because it's the same as the target > language. > > FORTH, if anyone remembers it, was booted-up by "user extension" from > a tiny collection of machine-coded primitives (a sort of one-eyed > p-code), which was partly why it was one of the first languages to be > ported to new platforms, and indeed was used to implement commercial > operating systems. Not very high-quality ones, I recall. But I don't > think the Burroughs Algol people did it that way: there was no > emulation going on. Nor could they have done it entirely like this: > > PLUS =: + > > The truth lay somewhere between. I would guess though it was basically > PLUS =: + but with the option to replace any definition with a > finer-grained one. Since the generation of a compiler is: source in, > machine-code out, there is no circularity in this. > > Do I take it from Roger's remarks that he has already got J > implemented in J? Or that he would use J to implement J if he had to > do it afresh? > > Ian > > > On Wed, Jul 22, 2009 at 4:27 PM, Dan Bron<[email protected]> wrote: >> If you were considering reimplementing J, which language would you use? >> What other tools would you use (e.g. yacc, antlr, parrot VM, etc)? >> >> Assume you're more concerned with productivity than performance in the >> first instance, but would like the option to tune performance in the >> future. >> >> What's a good language for implementing other languages? >> >> -Dan >> ---------------------------------------------------------------------- >> 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
