Read on Twitter
If you ever write a compiler, I have some advice for you:
(a thread)
(a thread)
- Don& #39;t be afraid.
- Keep your terminology consistent. It& #39;s more important here than in most programs.
- Write down your grammar. If you can& #39;t write it down, refactor until you can.
- Keep your terminology consistent. It& #39;s more important here than in most programs.
- Write down your grammar. If you can& #39;t write it down, refactor until you can.
- Inventing syntax is a responsibility. Take the time to experiment on paper.
- If you& #39;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& #39;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& #39;t expose that.
- Work on understanding what concepts belong where, and what& #39;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& #39;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& #39;re there, and why, and don& #39;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& #39;s worth to you, measured in code size. Drop fancy stuff if it& #39;s over-budget.
- You don& #39;t need to process strings. If you& #39;re doing it, you& #39;ve overcomplicated things.
- You don& #39;t need to process strings. If you& #39;re doing it, you& #39;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& #39;s a spec.
- Target several platforms. It helps for tests.
- Have your error messages quote section numbers for the spec, if there& #39;s a spec.
- It doesn& #39;t matter how many phases you have. You can add or remove phases later.
- Phases exist because it& #39;s time to move to a new datastructure.
- Phases exist because it& #39;s time to move to a new datastructure.
- Do all you can with the current datastructure, and then it& #39;s time to move to a new datastructure. If you don& #39;t need to do new things, you don& #39;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& #39;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& #39;t rely on general purpose debugging tools, when you can see your internal state in its own native format, free of superficial distractions.
