http://news.ycombinator.com/item?id=834175

Writing it in ML may be nice, but nobody wants to install ML just to get at another language. The kind of person that would do this is probably aspiring to a good language implementation of their own that could be considered a /peer/ of ML (or Perl, or Python, or Scheme, or Java, or....). High level languages written in yet another high level language are more of an academic curiosity than a tool anyone's likely to use.

While, yes, you're talking about prototyping, that assumes doing so in ML is much simpler. Maybe for you, but not for a C/C++ coder who doesn't know ML. There are a very, very large number of such coders.

Why write a prototype then have to rewrite the whole thing in C to have a "serious" language implementation? For small languages, the effort spent in prototyping then rewriting is going to be more effort than just writing a good stand-alone implementation from the outset. My hobby "prototype" compilers are small, portable, fast, depend on almost nothing, and integrate with the system and command line nicely. If the language was to become useful embedded in some program, say, I could do so immediately because I wrote the implementations to be good from the start. As a user, I'd take that over something I have to run in ML or some other massive high level language any day...

Would it be nice if the system's language was something better (somewhat) like ML? Sure. Is it? No.

Anyway, from the implementation point of view, when it comes time to write your GC, or any other low level details (parallelism?) writing in something like ML is a severe handicap. As far as performance goes, LLVM makes /fast/ code, and a lot of work is constantly being poured into it by a lot of people to make it even faster. This is a HUGE amount of work (i.e. far beyond what one person writing a language, or the people involved in the projects you have mentioned, can or will do), and it's already been done for you if you use LLVM (of course LLVM does have ML bindings).

Anyway, the point is, if you're trying to "prototype" or do PLT research, and you know ML well, and all you care about is the language itself you're implementing (and not the qualities/bloat/dependencies/performance of the implementation); sure, using ML probably makes sense. However these things are certainly not true of everyone writing a compiler.

Forget the word "compilers" for a second. Pick the most powerful language you can find for experimenting with graph algorithms.

That's it. That's all it boils down to. Compiler bloat, running speed, start up time and other stuff is just a programmer's wishful thinking. How many machines in the world run your software? how much of your user's time have you wasted by not implementing a piece of software as efficiently as you could? (would your users trade delivery time for startup or running time? i.e. do they want to start using your program today, even if it runs 300% slower than the machine allows, or do they want to use it next week and expect it to run at maximum speed? :-)

Comparing ML to Perl or Python is ridiculous. There are a number of native optimizing compilers of ML. ML is closer to C++ or Java or CL performance-wise than to those languages.

Now we don't see your guideline but do see Flex/Bison/LLVM one.

I mean, more meat, examples, and soon quite a few more people know how to prototype a language in SML.

While it uses SML, it's not hard to follow if you use OCaml, and the bibliography / references are also quite helpful. The Ghuloum paper referenced elsewhere in the thread is also quite good (and uses Scheme, for better or worse).

Sad.

If you're completely lost, try starting with interpreters first. Compilers build on many of the same ideas, but interpreters are generally simpler. Read "The Art of the Interpreter" and/or SICP, and do the exercises. The former is a short paper, the latter is an excellent book expanding on it.

There are dozens and dozens, if not hundreds of articles and "how to" style pages on the web showing a concrete implementation of a small compiler for a toy language using lex/flex and yacc/bison, yet when asked for something similar in ML, SML, Haskell, whatever, the response is to be pointed at books and scholarly articles.

Where are the popular accounts of better compiler building with ML? Are there any? If not, why not?

Yes, building an industrial-strength compiler for a real-world langauge is a big and complex undertaking, but I feel the field would advance more quickly if more hackers had more access to more articles of the "Build a compiler in an afternoon" variety.

And I'd appreciate learning from it too, despite, or perhaps because of, my existing knowledge.

Here's[1] a post about an OCaml / LLVM article by Jon Harrop, but it's just an intro for an article in his (pay) OCaml Journal.

   [1]: http://ocamlnews.blogspot.com/2008/09/writing-bytecode-compiler-using-llvm.html

I'd love to see how clever they are, applaud them for it, and build on their work. They don't seem to care.

I'm curious about writing interpreters / compilers in Prolog (another language that seems particularly suited to prototyping them), as well, but I've already got plenty of projects.

Just a short article showing how to get things done.

Exactly as one we're discussing.

Yeah, go for it...

Revisit the recent drama with twisted vs tornado.

By researching independently when given sufficient pointers. I posted a link to Abdul Azziz Ghoulum's paper which shows a full compiler in small baby steps, bootstrapped from the first line!

Research and conference papers are fairly good for learning, almost as good as blog posts.