4 ms·

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 optimi

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 3y ago
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 3y ago
  True, but no need to self-gatekeep the terminology here just to appease a rando commenter. :)
ozim 3y ago
Yes draw two circles and then the rest of the owl kind of thing.
eichin 3y ago
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...
sebastianmestre 3y ago
Parsing and symbol resolution on simple languages is kinda trivial in my opinion, but I'll probably write some articles about that stuff later Control flow and pointers are coming in the next part, and it's still surprisingly easy
- phtrivier 3y ago
  Is memory / register allocation in your roadmap too ? (honest question, I'm not sure it's in the scope of your articles)
  - sebastianmestre 3y ago
    Register allocation is not on the roadmap, I think it's too hard for this series... But maybe I just haven't figured out an easy enough way to do it yet :^) Memory allocation? You mean making a heap allocator? In the spirit of lowering the bar for creating new languages, I lean more towards calling into libc's malloc instead of building a custom solution haha

cmrdporcupine 3y ago

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 3y ago
True, but no need to self-gatekeep the terminology here just to appease a rando commenter. :)

ozim 3y ago

Yes draw two circles and then the rest of the owl kind of thing.

eichin 3y ago

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...

sebastianmestre 3y ago

Parsing and symbol resolution on simple languages is kinda trivial in my opinion, but I'll probably write some articles about that stuff later Control flow and pointers are coming in the next part, and it's still surprisingly easy

phtrivier 3y ago
Is memory / register allocation in your roadmap too ? (honest question, I'm not sure it's in the scope of your articles)
- sebastianmestre 3y ago
  Register allocation is not on the roadmap, I think it's too hard for this series... But maybe I just haven't figured out an easy enough way to do it yet :^) Memory allocation? You mean making a heap allocator? In the spirit of lowering the bar for creating new languages, I lean more towards calling into libc's malloc instead of building a custom solution haha