Re: Compiler implementation language preference ?

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!)


GnuBC has a (largely eliminable) layer of bootstrapping to compile its
predefined libraries into itself.


Knuth's TeX engine is built on top of the (context-sensitive) parser in Web
and/or cweb. The "tangle" and "weave" programs are the core that has to be
bootstrapped. Tangle is Web->Pascal (ctangle cweb->C); weave is Web->TeX,
cweave is cweb->TeX; (and all this is a setup for TeX.web, which has to be
compiled via Web).


Go is also self-built.


A notable gap is that Yacc is not self-compiled; thereby falling short of the
"is it worth using" test!


Code synthesis tools (indent, yacc to some degree, web) are difficult to do
with traditional parsers; since synthesis -- which is an application of the
field of "pragmatics" not "syntax"(!) -- means you have phrase structure
rules, but no start symbol! Instead, you process maximal parsable chunks; and
that generally is what requiring a context-sensitive parser. That's because
the source language has macros (in the case of Web, at least, that's the
reason). Translators all fall into this class too, particularly if the
language has macros. Those have to be handled correctly ideally without
breaking open the black box into the translator output.


The self-compile trick could be extended to theorem provers, since proof
algebras themselves are ... algebraic formalisms. I put up a small part of
Lambek-Scott's higher-order categorical logic/type-theory formalism on top of
Prover9-Mace4 (with difficulty), for instance. A bigger challenge might be to
try to bootstrap compile Martin-Loef's type theory on top of Automath; since
it is a (self-admitted) descendant of Automath.


Fortran prakrits (to coin a phrase) could be bootstrapped on top the old
Sanskrit Fortran (to coin another phrase) by good compiler-writer like ...


> ...but I wouldn't write a new
> compiler in Fortran because it doesn't have great data structuring or
> dynamic storage management. (Yes, I know that Fortran 2008 is a lot
> different from Fortran 66.) -John]


... John. (It's still an idea, ad-hoc extend the language you write it in and
use scripts to reduce it to Sanskrit in mid-process.)

Return to the comp.compilers page.
Search the comp.compilers archives again.