15 comments

[ 2.0 ms ] story [ 93.8 ms ] thread
Awesome to see Fortress mentioned, even if it is about its untimely demise :(

There was a lot to like about it, and how ahead of its time it was: safe parallelism, a powerful type system, extensible syntax; but ultimately its ambition and overall weirdness in how it looked made it hard to digest.

I wonder if this is also partly because of the available literature.

We have no shortage of introductory texts on writing compilers or interpreters, but often these seem to spend hundreds of pages on lexing and parsing, so you can read your source code and turn it into some beautifully designed AST, and then about five pages on subsequently turning that AST into something useful. What they do have is usually very simple examples implementing local variables and maybe a basic control structure or two in an imperative language.

There is relatively little available at a more intermediate to advanced level. Which books describe in detail how to implement different kinds of runtime infrastructure, such as garbage collection or exception handling or dynamic loading of shared code? What about different strategies for implementing the basic behaviour of the program, such as compiling with continuations instead of using nested stack frames for everything? Suppose you want to implement closures and you're considering how they could interact with some new memory model you're using; where do you look for advice and learn about any relevant prior art? What optimisation strategies have been discovered that could be useful once you have a simple first implementation?

There are answers to these kinds of questions out there, but often they are scattered among academic papers, videos from small conferences or ten-year-old discussions on twenty-year-old discussion websites. There are a few books addressing some of these points, but they are relatively obscure.

Any recommendations for introductory text for writing compilers and interpreters?
What sort of language are you interested in implementing? Once you've got past the lexing and parsing stages, the implementation strategy can be quite different for, say, a functional-style language and an imperative OO-style language, so it would be helpful to know more and then perhaps some of us could suggest suitable material.
Preferably something with the syntax of Java.
His point is that syntax is nearly the most irrelevant part of language implementation.

- "I want to build a house"

- "OK, what kind of house"

- "Preferably red"

I think "Programming Languages: Application and Interpretation" does much of what you want: in particular, it takes the view that "from our perspective parsing is mostly a distraction, because we want to study the parts of programming languages that are not parsing." The author, Shriram Krishnamurthi, puts the complete text online for free at http://cs.brown.edu/courses/cs173/2012/book/
From what I've seen, toy implementations of ML-family functional languages are very popular subjects of compilers textbooks and courses.

(By shocking coincidence, the same courses often use ML-family functional languages as the implementation language...)

Most languages these days are open source; reading source code from a real implementation is a great way to learn.
The trouble is, that's a little like saying Linux is open source so if you want to learn how a real world operating system is implemented you can just go and read the kernel code. While technically true, without any sort of guide to which parts are important and what the big picture looks like, it's difficult for a beginner to know where to start.
A basic implementation of a language is easy, I did it as a part of CS curriculum. It's the "boring" parts that stop most of the languages from becoming useful outside toy projects. Does your language have a profiler? How's support for debugging? Suppose there's a memory leak. Can I peek into "what has been allocated" without writing the instrumentation myself?
> Does your language have a profiler? How's support for debugging? Suppose there's a memory leak. Can I peek into "what has been allocated" without writing the instrumentation myself?

No it doesn't because I did not need that yet. Here is how your little language can get its first user: don't try to conquer the world with it right away. Conquer your own desktop first.

It obviously does not have to. I was just saying that this is both necessary for adoption and takes a lot of effort to implement.