It depends. OCaml is great for compilers, but having the compiler of a language in that same language lowers the barrier of entry for contributors and could lead to more innovation down the road.
I don't see this as an issue, the fact that OCaml is such a great compiler language means that plenty of good compiler writers already know and use OCaml.
Facebook wrote the compiler for their Hack language (basically a better PHP) in OCaml, for example.
Bootstrapped compilers are nice but can come later, after the language gains traction in the community. This language is brand new.
I have never understood this (admittedly common) mindset. if writing a compiler does not play to your language's core strengths, what have you gained by insisting on bootstrapping it? you might argue that writing a compiler provides a good stress test of the language and stdlib, but so would identifying a large project that does play to its strengths, and developing it in parallel with the language.
and contrariwise, bootstrapping a compiler might even be a net negative, not just because you have passed up on the chance to use a language that is better suited to the task, but because you have complicated your build process, created potential morasses when you have bugs with both your language design and your compiler implementation and you can't fix them separately, and are implicitly prioritising those features of your design and implementation that are useful for writing compilers, even though that might not be a very large use case for it at all.
in the days where people were building up from assembly, bootstrapping compilers made a lot of sense. but now that there are existing, well established languages that have proven their value in the specialised problem domain, it makes no sense to ignore them and insist on bootstrapping for its own sake.
Any Turing complete language can be used to write compilers.
For me bootstraping is the best way of testing if the language design is sound and to become independent of other tooling. As you happen to mention.
Many language designers that don't follow this process, happen to never fully experiment with their own language, as they spend most of their time in the compiler.
As for tooling, the overlying of many designers in C and similar toolchains has created the wrong belief that only the said languages can be used to write compilers. To the point of the famous statement in the language design community "My compiler compiles yours".
For me, the only place where bootstraping is to be avoided are DSLs.
The risk is that instead of designing your language with your original goals in mind, you bend the design to suit the task at hand - writing a compiler. You add features that you wouldn't otherwise, because they make that job easier, and then they remain as ugly warts for the rest of the language's life.
Also, compilers are a particular subset of programs - they're pure functions. By bootstrapping do we end up with nothing but languages suited for this kind of problem?
So Rhine, being a Lisp, may not be a good language for implementing a big pure function involving a lot of tree transformations. Is that what I'm reading?
If your goal is to write a language that is very good for writing compilers, then bootstrapping is probably a great idea. If you have other goals, such as being well suited to CRUD applications, concurrency, parallelism, graphics, you may find that bootstrapping is not the most productive activity.
More broadly, if your goal is to produce a useful language, why would bootstrapping help you achieve that goal, beyond writing any other system in your language?
I certainly can imagine that tradeoff happening, in the abstract at least.
Was there a language/compiler combination that you worked on where you experienced this pitfall first hand, are there historical anecdotes from language/compiler authors, or did you arrive at this a priori?
ML? I believe the genesis of 'Meta Language' and 'Standard Meta Language' was language design being done by people who wrote nothing but experimental compilers. Not sure how often they were bootstrapping, but it would be a similar issue.
Solarsail -- not true. For one example, BNF is a meta-language (a language about language), and it is extremely useful in the real world.
As the author of a computer language expert system, I refer to its rules language as a meta-language (and rules as meta-code) because it manipulates language content symbolically. And, as it happens, it actually executes BNF in order to parse the languages it consumes, the BNF being delivered to it via that same rules language.
Code content represented in my system's Internal Representation (IR) is not itself a meta-language; it's more of a "super-language", being synthesized across real languages. But that IR's architecture does comprise a kind of meta-language; because it is a structure that represents language content in an abstracted way, it is "about" the very concept of a computer language.
As the author of such a system, I do meta every day, meta-meta often, and triple-meta occasionally.
Sounds like an interesting project. I didn't point ML to say that meta-languages generally or ML itself were useless. Rather, that ML is specialized in a way that wouldn't aid in writing things completely unrelated to compilers. (Tho I hadn't thought of using one in an expert system.) Say, writing relational databases, game AI's or GUI interfaces.
So, what is zhe point here?
That writing a compiler in your new language is a good way of dogfooding? Wouldn't that mean that any other complex application would do?
Or is it that most new languages are more powerful than the portable languages (Java, C, Javascript) they are written in, and should thus ease the pain in compiler writing?
FTR, the first version of gcc was written in Scheme, but even the c++ frontend of gcc is written in c rather than c++
I wrote a little about the guts of the Rust compiler earlier this year. Shouldn't be too out of date, should get you pointed in the right direction if you're interested in the details:
