> 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 /.)
See the description for the monad ;: http://www.jsoftware.com/help/dictionary/d332.htm > 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. It could be as simple as I suggested. The inverse for the monad ! provides a glimpse into the magic underneath: ] a=: !^:_1 ]10 100 1000 10000 3.39008 4.89252 6.17418 7.33625 ! a 10 100 1000 10000 ! b. _1 3 : '(-(!-y"_)%1e_3&* !"0 D:1 ])^:_ <.&170^:(-:+)^.y' :.! If you are serious about implementing J you should read Ken's APL87 paper, APL87: http://www.jsoftware.com/papers/apl87.htm ----- Original Message ----- From: Ian Clark <[email protected]> Date: Wednesday, July 22, 2009 17:15 Subject: Re: [Jprogramming] Reimplementing J To: Programming forum <[email protected]> > 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
