Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: gah4 Newsgroups: comp.compilers Subject: Re: STEP compiler generator Date: Fri, 17 Jun 2022 15:13:33 -0700 (PDT) Organization: Compilers Central Lines: 30 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-06-046@comp.compilers> References: <22-06-045@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="40320"; mail-complaints-to="abuse@iecc.com" Keywords: tools, history, comment Posted-Date: 17 Jun 2022 23:20:17 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <22-06-045@comp.compilers> Xref: csiph.com comp.compilers:3075 (I wrote) > http://www.bitsavers.org/pdf/stanford/slac/The_STEP_Processor.pdf I wasn't expecting a lot of discussion, but I thought someone might say something. I was thinking, though, about how it might be done today. Taking the core parser generator from Bison, that is without the I/O routines so it could be included in another program for a start. Then a new program to use the generated parsing table, similar to the way STEP interprets its generated parser. A new language to write actions instead of generating C code. Bison parsers depend on the output being processed by a C compiler. I suspect that most Bison users use only a small subset of C in their actions, so one could define a subset, or a new language for writing actions. Either one would allow for a simple compiler and the ability to interpret its output. One thing about STEP, is that as each rule and replacement procedure is compiled, is linked with the running system, and is immediately available for use. That is unlike the usual use of Bison, where the whole thing is compiled at the end. [Reminds me of IMP72 where you could put new syntax rules in your program and either make them a macro or call internal routines. It seemed like a good idea at the time but what it meant was that no two IMP programs were written in the same language and they tended to be unreadable. -John]