←back to thread

429 points rui314 | 7 comments | | HN request time: 0.267s | source | bottom
Show context
sdegutis ◴[] No.10731279[source]
Thought this was going to be an inspiration to me to continue with my pet project of writing my own little programming language. But it starts off on day 8 with him already having written a basic compiler, with no explanation of how he did any of the basics. Still interesting, just not what I thought it was.
replies(5): >>10731293 #>>10731295 #>>10731322 #>>10731384 #>>10731600 #
1. c4n4rd ◴[] No.10731322[source]
Same here. I have been trying the same project as you... and get stuck on the grammar, every.single.time.

Are you done with that part yet?

replies(6): >>10731391 #>>10731413 #>>10731690 #>>10731969 #>>10733429 #>>10736115 #
2. jerf ◴[] No.10731391[source]
What do you mean "stuck on the grammar"? Can't figure out how to write a grammar, can't get all the fiddly implications correct so OOO fails, can't figure out how to write the parser, can't muster up enough enthusiasm to finish the work...?

One option is to punt for a bit and use what I sometimes call the "Lisp non-grammar", even if you don't intend to be writing a Lisp; use parentheses to directly encode a parse tree, and whatever other hacky symbols you need for now to set up atom types or whatever. You might still be able to explore enough what you're interested in to figure out what you want in the grammar. Whatever the core idea of your toy language is, you should try to get to that as quickly as possible, punting on everything else you possibly can, so if the point of your language isn't to have an innovative new grammar, you might want to try to defer that work.

3. arcatek ◴[] No.10731413[source]
On which parts exactly are you stuck? I've rolled with Ragel as lexer, and Lemon as parser, and it was relatively simple.

[1] https://github.com/castel/libcastel/blob/master/parse/source...

[2] https://github.com/castel/libcastel/blob/master/parse/source...

4. zerr ◴[] No.10731690[source]
It's fine. "Compilers" topic is too wide. There are lot of sub-topics. I personally find lexing/parsing rather boring. It's after I have AST is when the fun begins for me (and right before actual/real code gen, where you have to know intricacies of particular CPU) :)
5. pjc50 ◴[] No.10731969[source]
The C grammar is printed in BNF in the back of K&R and available in machine-readable form in the standards.
6. sdegutis ◴[] No.10733429[source]
I haven't finished any part of it yet. My goal is to write a small language entirely in C. It would have a lexer, parser, bytecode compiler, stack based bytecode VM, and GC. It would only have numbers, strings, and functions to start with. That would be my "hello world" that I can build on to add new features. And since it would all be written in C, it could be easily embeddable. So my goal is to make it similar to Lua, except with a nicer API for embedding. I've got some vacation days coming up and hope to make some progress on this during that time.
7. PeCaN ◴[] No.10736115[source]
Let me guess, you're stuck fighting yacc and shift-reduce conflicts?

I find writing your own parser to be much more instructive and a better way to understand why parser generators work the way they do.

Alternatively you can use a PEG generator such as peg/leg[1] and your grammar will more or less work (until it resolves an ambiguity in some way you didn't expect, anyway).

1: http://piumarta.com/software/peg/