Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <157-073-9834@kylheku.com> Newsgroups: comp.compilers Subject: Re: Compiler implementation language preference ? Date: Sat, 10 Nov 2018 04:20:00 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 39 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <18-11-004@comp.compilers> References: <18-05-009@comp.compilers> <18-11-001@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="86514"; mail-complaints-to="abuse@iecc.com" Keywords: design Posted-Date: 10 Nov 2018 23:10:48 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2116 On 2018-11-09, rockbrentwood@gmail.com wrote: > On Tuesday, May 22, 2018 at 12:39:07 PM UTC-5, Michael Justice wrote: >> Is there any preference to writing a compiler in say c instead of say >> java, fortran, basic etc? I ask cause i see many of the projects using >> either c or c++ instead of other programming languages. >> >> nullCompiler >> [Mostly people use what they're used to, or in languages that are easy >> to bootstrap on the machines they want to use. > > A test of whether the language, itself, is worth using -- assuming it is a > general purpose language -- is whether you'd be willing to write the compiler, > itself, in it! I put up a branch (and heavily recoded) version of cparse on my > machine, which is in C and has 3 layers of self-bootstrapping. GCC has several > layers of self-bootstrpping, depending on what you implement from it (and > distressingly, it has -- as of version 6 -- acquired *dependencies* on > libraries further upstream! That's a major no no!) A nice bootstrapping method is to build an interpreter for the language also in some widely available language (like C). The compiler can be executed by the interpreter to compile itself, plus any other run-time support code also written in that language. If the compiler produces that widely-used systems programming language, then it can just be redistributed in compiled form and an interpreter need not be included. That's a tough way to evolve the language, though. An interpreter gives you a version of the language that is immune to bootstrapping chicken-egg problems and provides a reference model for what compiled code should be doing. You can always revert to the interpreter when things go horribly wrong. When you make modifications to the compiler and they are so wrong they break the compiler, you don't have to revert them. Just blow off all the compiled materials, try too fix your work in the compiler and just bootstrap from scratch through the stable interpreter. You never need a last-known-good copy of the compiler in your workspace.