Read on Twitter
If you ever write a compiler, I have some advice for you:
(a thread)
(a thread)
- Don't be afraid.
- Keep your terminology consistent. It's more important here than in most programs.
- Write down your grammar. If you can't write it down, refactor until you can.
- Keep your terminology consistent. It's more important here than in most programs.
- Write down your grammar. If you can't write it down, refactor until you can.
- Inventing syntax is a responsibility. Take the time to experiment on paper.
- If you're not sure how a language feature should go, do something you are sure about, first. It helps to get solid things in place.
- If you're not sure how a language feature should go, do something you are sure about, first. It helps to get solid things in place.
- Think of tokens as a stream. If you do buffer them up, don't expose that.
- Work on understanding what concepts belong where, and what's responsible for what.
- Phases have no business constructing things the previous phase constructed. Do repeat yourself, if it helps this.
- Work on understanding what concepts belong where, and what's responsible for what.
- Phases have no business constructing things the previous phase constructed. Do repeat yourself, if it helps this.
- You may have concepts from your output language directly visible in your input language. If you do, know why they're there, and why, and don't let that influence unrelated things just because they happen to be around.
- Please, please keep good separation between your phases.
- Please, please keep good separation between your phases.
- Before you implement something, keep an idea of how much it's worth to you, measured in code size. Drop fancy stuff if it's over-budget.
- You don't need to process strings. If you're doing it, you've overcomplicated things.
- You don't need to process strings. If you're doing it, you've overcomplicated things.
- For inputs and outputs, try to add a few diverse alternative formats. It helps sort out your internal assumptions.
- Target several platforms. It helps for tests.
- Have your error messages quote section numbers for the spec, if there's a spec.
- Target several platforms. It helps for tests.
- Have your error messages quote section numbers for the spec, if there's a spec.
- It doesn't matter how many phases you have. You can add or remove phases later.
- Phases exist because it's time to move to a new datastructure.
- Phases exist because it's time to move to a new datastructure.
- Do all you can with the current datastructure, and then it's time to move to a new datastructure. If you don't need to do new things, you don't need a new phase.
- Make your generated code look nice. Have a sense of care and pride.
- Output comments.
- Output comments.
I almost forgot!
- Add the ability to dump everything to Graphviz.
Don't rely on general purpose debugging tools, when you can see your internal state in its own native format, free of superficial distractions.
- Add the ability to dump everything to Graphviz.
Don't rely on general purpose debugging tools, when you can see your internal state in its own native format, free of superficial distractions.
