> 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.
I was not trying to recommend specific primitives. What I was saying was that it'd be very useful (very productive) to be able to implement this or that facility in J, such as 1 : '=...@[ u...@# ]' for /. or 3 : '(-(!-y"_)%1e_3&* !"0 D:1 ])^:_ <.&170^:(-:+)^.y' for the inverse of ! . ----- Original Message ----- From: Ian Clark <[email protected]> Date: Wednesday, July 22, 2009 19:03 Subject: Re: [Jprogramming] Reimplementing J To: Programming forum <[email protected]> > > 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
