Re: self-hosting, was Writing A Plain English Compiler

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> "BartC" <bc@freeuk.com> writes:
>>It does, however, run into problems, such as frequently ending up with
>>non-working compilers and/or support programs, and with most of the
>>bridges
>>burnt! Then recovering can be tricky.
>
> To deal with that, you have a "stable" and executable (or buildable)
> version somewhere, and make sure that your compiler builds with that
> version. So if the current version no longer builds with itself, you
> build it with the stable version; for that you also need a simple way
> to switch from building with the current version (default) to building
> with the stable version.


There are still problems, especially with on-going development of a language
and its compiler.


For example, you make an enhancement in the language. The compiler source is
modified, and the change is tested and it works. Then you decide to make use
of the new feature in the compiler code.


The problem comes when something else doesn't work and you need to revert
back, but those old binaries will not support the new feature that now
litters the compiler sources!


In the case of bytecode languages, there is a more specific problem: the
bytecode format could be modified in such a way that new binary bytecode
files will be incompatible with both old bytecode files, and with the
interpreter used. (This might be as simple as adding a new bytecode
instruction.)


Now, with a self-hosting system where all the support programs (the
compiler, any loader (a program that does a similar job to a linker but for
bytecode), libraries, and even IDEs and editors) will all be using version
X, and the interpreter runs only version X, everything needs to be switched
over to version Y. But everything can't be done simultaneously, so it gets
messy (with X-X, X-Y, and Y-Y versions being involved).


Without self-hosting and using external tools maintained by someone else,
most of these headaches would disappear. (I do it because I like the
satisfaction of being independent.)


"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message


> Another reason to self-host a compiler is the signal it sends: If you
> claim that your language is general-purpose, and you write the
> compiler for it in a different language, you are obviously not very
> convinced of the capabilities of your language, so why should anybody
> else use it?


Sometimes you have to use a different language to get started. Or you may be
modifying a compiler which is in another language (perhaps one of yours) to
compile a new language, and it would be silly to rewrite it in the new
language just for the purpose of being able to say it's self-hosted.


Another problem with self-hosting is distributing the program so that
someone else can use it. But is that done as a binary executable, or as
source-code?


With source-code in a new language, no-one will yet have a working binary
compiler to build it! While binary distributions have all the usual problems
(of supporting multiple platforms and getting people to trust it).


(If I was distributing a new language compiler, it would likely be in the
form of a single C source file. However, because my compilers aren't written
in C, and are interpreted, that single file would actually be the
interpreter, plus the compiler bytecode represented as data within the C
source.)


--
Bartc
[That's fine -- tools like bison are written in themselves, but they
distribute enough C code to bootstrap it. -John]

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