> If you are serious about implementing J you should > read Ken's APL87 paper, APL87: > http://www.jsoftware.com/papers/apl87.htm
Right. That will be my *next* project... Yes I am serious. I tend to learn more about language primitives by studying the implementation than I do from reading the user documentation. ...and as the "porter" to the Macintosh in the IAPL project, I have more than a passing interest in implementing interpreters. (Also inverting functions defined in terms of expressions). I am aware there are smarter ways of schedulling semantic function calls than a while-select-loop through a string of primitives. :-) And, yes... thanks for reminding me ;: doesn't just recognise J-words. Its implementation is cousin to a Turing machine: surely a sufficiently generalised engine for the purpose. This stands the FORTH approach on its head, and I was wrong to dismiss it althogether. So what you're saying is I need to revisit the idea of reimplementing J at boot-up time from a tiny kernel of primitives... not naive ones as in FORTH but very sophisticated ones like ;: and ^_1. Ian On Thu, Jul 23, 2009 at 1:31 AM, Roger Hui<[email protected]> wrote: >> 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
