3 ms·

No dependencies but the very first step relies on a dependency? It's not because you copy-paste it that it's not a dependency...

eatonphil 4y ago
He also used a compiler, and a standard library, and a computer.
- iLoveOncall 4y ago
  There's a bit of a difference between taking away the only truly hard part of the project and using the standard library.
  - eatonphil 4y ago
    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
lelandbatey 4y ago
The first dependency is a "dependency", but in the same way that an RFC you have to read with your eyes is a dependency. Except in this case, the dependency is a definition, in formal language (extended-backus-naur form, a.k.a. "e-bnf"), of the SQL language, as defined in ISO/IEC 9075:2016[0] (the 2016 version of the SQL language specification). They then use this language definition as the input to a program which generates parsers (called a parser-generator[1]), so that they can quickly get to where they have a library which they can use to parse/validate/inspect the SQL being given to them. Copying the BFN "from an external source" is a smart move, since it means they don't have to do lots of busy work slowly reading and transcribing the specification; someone's already done that step, so why would anyone expect the author to waste time? Using a parser generator is also a smart move since they exist already and are used all over the place (nobody hand-writes parsers for large languages; that's just a needless source of tedium and bugs). The code that's spit out of the parser generator is novel; that's newly created code which isn't taken from someone else's Github/other repo. Ultimately, I don't see how any of what the author's done constitutes "[relying] on a dependency" given that they're not using anyone elses Zig source code in their compiled binary, they're writing lots of code for themselves to use, just very quickly, and with powerful tools. [0] - https://en.wikipedia.org/wiki/SQL:2016 https://en.wikipedia.org/wiki/SQL:2016 [1] - https://en.wikipedia.org/wiki/Compiler-compiler https://en.wikipedia.org/wiki/Compiler-compiler
- eatonphil 4y ago
  > nobody hand-writes parsers for large languages; that's just a needless source of tedium and bugs That is absolutely not true! In fact, most major programming language implementations use handwritten parsers [0]. That said: > Using a parser generator is also a smart move since they exist already Jamie wrote the parser generator here too. So it's all the more "from scratch". [0] https://notes.eatonphil.com/parser-generators-vs-handwritten-parsers-survey-2021.html https://notes.eatonphil.com/parser-generators-vs-handwritten...

eatonphil 4y ago

He also used a compiler, and a standard library, and a computer.

iLoveOncall 4y ago
There's a bit of a difference between taking away the only truly hard part of the project and using the standard library.
- eatonphil 4y ago
  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

lelandbatey 4y ago

The first dependency is a "dependency", but in the same way that an RFC you have to read with your eyes is a dependency. Except in this case, the dependency is a definition, in formal language (extended-backus-naur form, a.k.a. "e-bnf"), of the SQL language, as defined in ISO/IEC 9075:2016[0] (the 2016 version of the SQL language specification). They then use this language definition as the input to a program which generates parsers (called a parser-generator[1]), so that they can quickly get to where they have a library which they can use to parse/validate/inspect the SQL being given to them. Copying the BFN "from an external source" is a smart move, since it means they don't have to do lots of busy work slowly reading and transcribing the specification; someone's already done that step, so why would anyone expect the author to waste time? Using a parser generator is also a smart move since they exist already and are used all over the place (nobody hand-writes parsers for large languages; that's just a needless source of tedium and bugs). The code that's spit out of the parser generator is novel; that's newly created code which isn't taken from someone else's Github/other repo. Ultimately, I don't see how any of what the author's done constitutes "[relying] on a dependency" given that they're not using anyone elses Zig source code in their compiled binary, they're writing lots of code for themselves to use, just very quickly, and with powerful tools. [0] - https://en.wikipedia.org/wiki/SQL:2016 https://en.wikipedia.org/wiki/SQL:2016 [1] - https://en.wikipedia.org/wiki/Compiler-compiler https://en.wikipedia.org/wiki/Compiler-compiler

eatonphil 4y ago
> nobody hand-writes parsers for large languages; that's just a needless source of tedium and bugs That is absolutely not true! In fact, most major programming language implementations use handwritten parsers [0]. That said: > Using a parser generator is also a smart move since they exist already Jamie wrote the parser generator here too. So it's all the more "from scratch". [0] https://notes.eatonphil.com/parser-generators-vs-handwritten-parsers-survey-2021.html https://notes.eatonphil.com/parser-generators-vs-handwritten...