[HN Gopher] Writing a Compiler is Surprisingly Easy (part 1)
___________________________________________________________________
Writing a Compiler is Surprisingly Easy (part 1)
Author : mmphosis
Score : 34 points
Date : 2023-11-07 20:36 UTC (2 hours ago)
(HTM) web link (sebmestre.blogspot.com)
(TXT) w3m dump (sebmestre.blogspot.com)
| mati365 wrote:
| * compiler without optimization phase
| TheChaplain wrote:
| Probably adheres to the principle; "Make it work, then make it
| fast"
| kevindamm wrote:
| It's actually three steps: make it, make it work, make it
| work faster.
|
| this may actually be somewhere between step one and two.
| phtrivier wrote:
| If I read the article correctly, it's actually "a compiler for
| a language that only supports basic arithmetic, without a
| lexer, a parser, symbols, nor an optimization phase".
|
| Which _is_ surprisingly easy to write. But it might be a
| stretch to call it "a compiler" :D
| cmrdporcupine wrote:
| Yeah, I've written stuff like this many times -- mostly
| producing AST then bytecode, etc. I never really wanted to
| call it a 'compiler' per se though that's what it is. Because
| I generally stand in awe of serious optimizing compiler
| engineers, they have deep domain expertise that is admirable.
| mattgreenrocks wrote:
| True, but no need to self-gatekeep the terminology here
| just to appease a rando commenter. :)
| ozim wrote:
| Yes draw two circles and then the rest of the owl kind of
| thing.
| eichin wrote:
| Eh, a college friend put together a C compiler in 100 lines
| of yacc (not particularly golfed, either, C just isn't that
| sophisticated.) Great for playing with "what if C + this one
| feature" kind of things in a concrete way. So from my
| perspective, not a stretch at all...
| acchow wrote:
| * compiler without good error messages
| musicale wrote:
| Clang may have better static checking, but Apple's MPW C
| compiler still had better error messages.
|
| https://news.ycombinator.com/item?id=37283375
| zem wrote:
| if you use the nanopass approach you can add optimisation
| phases relatively easily
| agumonkey wrote:
| but since he hardcodes the register allocation, i wonder how
| he can control anything here
| zem wrote:
| you can refactor over time to add a register allocator. the
| key point is it's usually easier to do these things within
| the context of an end-to-end working compiler than with a
| big design up front.
| mepian wrote:
| As opposed to a tree-walking interpreter, which is usually
| presented as the only viable way to write your first
| programming language implementation.
| mamcx wrote:
| Aka: a compiler.
|
| A compiler is just `source -> generate -> target`. All the
| other fancy things are optional. IMPORTANT things, but don't
| detract from calling it a "compiler".
|
| ---
|
| This is similar to anything else: A single `.html` served on
| `:80` is a website. A 2d, grayscale `pacman` is a videogame.
| `print("hello world")` is a program, etc.
| t14n wrote:
| I like the sentiment of the title, even if it gets people riled
| up. I'm fondly reminded of the introduction from Bob Nystrom's
| _Crafting Interpreter_ [1]
|
| > This last reason is hard for me to admit, because it's so close
| to my heart. Ever since I learned to program as a kid, I felt
| there was something magical about languages. When I first tapped
| out BASIC programs one key at a time I couldn't conceive how
| BASIC itself was made.
|
| > Later, the mixture of awe and terror on my college friends'
| faces when talking about their compilers class was enough to
| convince me language hackers were a different breed of human--
| some sort of wizards granted privileged access to arcane arts.
|
| > It's a charming image, but it has a darker side. I didn't feel
| like a wizard, so I was left thinking I lacked some inborn
| quality necessary to join the cabal. Though I've been fascinated
| by languages ever since I doodled made-up keywords in my school
| notebook, it took me decades to muster the courage to try to
| really learn them. That "magical" quality, that sense of
| exclusivity, excluded me.
|
| > And its practitioners don't hesitate to play up this image. Two
| of the seminal texts on programming languages feature a dragon
| and a wizard on their covers.
|
| > When I did finally start cobbling together my own little
| interpreters, I quickly learned that, of course, there is no
| magic at all. It's just code, and the people who hack on
| languages are just people.
|
| > There are a few techniques you don't often encounter outside of
| languages, and some parts are a little difficult. But not more
| difficult than other obstacles you've overcome. My hope is that
| if you've felt intimidated by languages and this book helps you
| overcome that fear, maybe I'll leave you just a tiny bit braver
| than you were before.
|
| 1: https://craftinginterpreters.com/
| musicale wrote:
| I like this approach, but why not take it one step further toward
| Turbo Pascal and generate the opcodes? ;-)
| JohnMakin wrote:
| Who needs a lexer, a parser, and an AST when you can just
| explicitly feed the tokens into a switch statement that
| completely falls through if it runs into something it doesn't
| recognize? This is super easy!
|
| Sorry, I am by no means a compiler expert, but spent enough years
| in study of them and taken enough stabs at writing my own that
| this take is hopelessly naive, and I really hope the author
| realizes it.
| mianos wrote:
| I have written multiple compilers, from C-like interpreters to
| protobuffer like compilers over the years, all in production,
| some still.
|
| Not doing a finite state machine for any stream interpretation
| is a huge mistake, just as much as it is outside of the
| compiler tokenisation, such as protocol decoders and even just
| parsing config files.
___________________________________________________________________
(page generated 2023-11-07 23:00 UTC)