No, I appreciate that. It's coming clear to me that you wouldn't need to identify a "kernel" of primitives at all. All the semantic functions of the old J, implemented in C, would be shipped in the new version. Judiciously these would be patched-out (overridden) by J-written algorithms. To check whether a given section of original code was redundant might be a far from trivial task -- and why bother?
I can't believe you haven't thought through all this yourself long ago, Roger, and know the answer already. I suspect you're challenging me. :-) Well, it's a challenge I might just take up. Ian On Thu, Jul 23, 2009 at 4:28 PM, Roger Hui<[email protected]> wrote: >> 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
