4 ms·

The SQL grammar is already defined. He didn't invent SQL. He had to take the grammar from somewhere. You wanted him to handwrite it copied from the ANSI SQL p

The SQL grammar is already defined. He didn't invent SQL. He had to take the grammar from somewhere. You wanted him to handwrite it copied from the ANSI SQL paper? Or to just think up all the possible grammars and ignore the real paper? How would that be different or better than this?

remram 4y ago
[[edit: NO HE DIDN'T!]] If you missed it, the author does more than reuse the grammar, he used a parser generator, which I think is what iLoveOncall is reacting to. Personally I do agree that, when writing a language interpreter and claiming "no dependency", grabbing an existing parser is a bit of a cheat. Just like grabbing an existing bytecode VM, garbage collector, just-in-time engine, ... would be. It doesn't make the endeavor less interesting or less formidable, but it doesn't really fit "no dependencies" any more.
- eatonphil 4y ago
  > If you missed it, the author does more than reuse the grammar, he used a parser generator, which I think is what iLoveOncall is reacting to. Huh? He wrote the parser generator. https://github.com/jamii/hytradboi-jam-2022/tree/main/lib/sql https://github.com/jamii/hytradboi-jam-2022/tree/main/lib/sq...
  - remram 4y ago
    That wasn't clear for me at all, reading the README, and I don't grok zig. Nevermind then, no dependencies indeed.
    - eatonphil 4y ago
      I don't mean to belabor the point but if you ctrl-f in the readme for "generator" you'll see: > I only have to parse sqlite grammar, and even then probably only a fraction of it. So it looks like writing a parser generator might be plausible and by now it's really my only option if I want to get any tests passing at all. > So here's my grammar so far. It's parsed by GrammarParser. In theory I could do this at comptime, but until we get a comptime allocator that's going to be a yak shave and I am way too many yak shaves deep already. So I laboriously but reliably write out all the rules into grammar.zig. > The Tokenizer is written by hand and seems to be basically done - it runs without complaint on the entire test set. I might discover bugs there later, of course. > The Parser is fun. There is a single parse function, but because it reads the rules from grammar.zig at compile time it gets specialized for each parse rule. Basically I got the same result as hand-generating the parser code, without having to splices a bunch of strings together. After the jam maybe I'll have some yak shave time to cut out grammar.zig entirely and do all the grammar stuff at comptime, and then it'll be a pretty sweet system. > The best part about this is that I get really nice parse trees by generating rich types from the input grammar. Eg. And also: > I made some changes to the parser generator, added a whole bunch of debugging tools to the parser itself and then sat down and cranked on the grammar till I can parse 100% of the tests. I'm finally out of the damn tunnel.
      - remram 4y ago
        From this I assumed that GrammarParser was a built-in Zig module for parsing and parser generation.
        deleted 4y ago
        [deleted]

remram 4y ago

[[edit: NO HE DIDN'T!]] If you missed it, the author does more than reuse the grammar, he used a parser generator, which I think is what iLoveOncall is reacting to. Personally I do agree that, when writing a language interpreter and claiming "no dependency", grabbing an existing parser is a bit of a cheat. Just like grabbing an existing bytecode VM, garbage collector, just-in-time engine, ... would be. It doesn't make the endeavor less interesting or less formidable, but it doesn't really fit "no dependencies" any more.

eatonphil 4y ago
> If you missed it, the author does more than reuse the grammar, he used a parser generator, which I think is what iLoveOncall is reacting to. Huh? He wrote the parser generator. https://github.com/jamii/hytradboi-jam-2022/tree/main/lib/sql https://github.com/jamii/hytradboi-jam-2022/tree/main/lib/sq...
- remram 4y ago
  That wasn't clear for me at all, reading the README, and I don't grok zig. Nevermind then, no dependencies indeed.
  - eatonphil 4y ago
    I don't mean to belabor the point but if you ctrl-f in the readme for "generator" you'll see: > I only have to parse sqlite grammar, and even then probably only a fraction of it. So it looks like writing a parser generator might be plausible and by now it's really my only option if I want to get any tests passing at all. > So here's my grammar so far. It's parsed by GrammarParser. In theory I could do this at comptime, but until we get a comptime allocator that's going to be a yak shave and I am way too many yak shaves deep already. So I laboriously but reliably write out all the rules into grammar.zig. > The Tokenizer is written by hand and seems to be basically done - it runs without complaint on the entire test set. I might discover bugs there later, of course. > The Parser is fun. There is a single parse function, but because it reads the rules from grammar.zig at compile time it gets specialized for each parse rule. Basically I got the same result as hand-generating the parser code, without having to splices a bunch of strings together. After the jam maybe I'll have some yak shave time to cut out grammar.zig entirely and do all the grammar stuff at comptime, and then it'll be a pretty sweet system. > The best part about this is that I get really nice parse trees by generating rich types from the input grammar. Eg. And also: > I made some changes to the parser generator, added a whole bunch of debugging tools to the parser itself and then sat down and cranked on the grammar till I can parse 100% of the tests. I'm finally out of the damn tunnel.
    - remram 4y ago
      From this I assumed that GrammarParser was a built-in Zig module for parsing and parser generation.
      - deleted 4y ago
        [deleted]