Live data from Hacker News

Glush: A robust parser compiler built using non-deterministic automatons

sanity.io

31–34 of 34 posts

Re: Glush: A robust parser compiler built using non-deterministic automatons

#31

> However, in practice it turns out that LALR(1) isn’t always the answer. For instance, both GCC, Rust and Go have chosen to use handwritten parsers that are not based on a declarative grammar file. I find this disappointing: We have decades of experience with specifying languages in a declarative format, and apparently it’s still easier to manually write parsers. Obviously there’s something lacking with the algorith…

(Author of the article here)

> Many production compilers have hand-written parsers because of error reporting, not because of issues with parser-generator algorithms.

Yes! I totally agree. Error reporting was one of the things I meant when I said that there is somethings "lacking with the algorithms we have today".

> The generated parser will not gracefully report a mismatched number of parentheses! Instead, it will report that the user's input is not formatted as expected, which makes it hard for the user to understand what went wrong.

I'm not sure if this is the best example. Ruby is using Bison for parsing and it's certainly able to detect a missing parenthesis:

    ruby -e 'p (1 + 2'
    -e:1: syntax error, unexpected end-of-input, expecting ')'
Most parser algorithms have a concept for "currently expected characters/tokens" and can easily report this on an error.

I also think that this will be more precise in Glush than in e.g. LR-based algorithms because Glush is following the grammar strictly top-down. It knows exactly which characters are allowed at any given moment.

I have however not made an effort to make nice error messages so I don't know how well automatic error reporting would work and I don't feel comfortable making any concrete claims or promises.

> It is possible to modify the grammar to look for this case specifically:

Not sure if I see much value in manually adding such a case. This seems like a case that would be easily handled automatically (again: see Ruby above).

> But now I've just polluted my once-pristine grammar file. And adding all of the necessary error checks throughout the grammar will really make things complicated.

Well, if you want the equivalent error reporting in a hand-written parser you also need to add an equivalent amount of code. There are probably ways you can annotate a grammar to improve error reporting and I think it's a far more interesting solution to investigate. I haven't experimented with this yet, but I'd love to try to tackle it if I can find the time.

Re: Glush: A robust parser compiler built using non-deterministic automatons

#32

Nice article, this looks like a useful parser generator. Though, as others have mentioned, error reporting is a very important point that should be considered even at this early stage. Here's something that surprised me though: > a parser toolkit that lets you create efficient parsers in multiple languages (currently JavaScript, Go, and Ruby) > [some other approach] it looked very interesting, but it’s not completely…

(Author here!)

> This isn't the author's only reason to dismiss that alternative approach, but it's still a strange point to spend almost an entire paragraph on. If all the targets the author currently envisions are GC'd languages, it's premature pessimization to worry about how other, hypothetical, targets might be accommodated.

Aah. I should probably have clarified that. At Sanity.io today we only need JavaScript and Go, and those are the most imminent languages to support (and what I can actually spend time on during work). However, as an overall parser algorithm I consider it crucial to be able to easily target C as this would unlock a whole new world of possibilities.

Does that make it more clear?

> but it's still a strange point to spend almost an entire paragraph on

Yeah, this article isn't exactly short on details. The purpose of this post was a mixture between (1) arguing for the value of declarative-based grammars, (2) showing all of the fascinating algorithms that have been discovered, and (3) showing how Glush works.

I've had a great time playing with Parsing with Derivatives so even if I didn't end up directly using it, I feel like sharing cool ideas to new people.

Re: Glush: A robust parser compiler built using non-deterministic automatons

#33
post #32

Nice article, this looks like a useful parser generator. Though, as others have mentioned, error reporting is a very important point that should be considered even at this early stage. Here's something that surprised me though: > a parser toolkit that lets you create efficient parsers in multiple languages (currently JavaScript, Go, and Ruby) > [some other approach] it looked very interesting, but it’s not completely…

(Author here!) > This isn't the author's only reason to dismiss that alternative approach, but it's still a strange point to spend almost an entire paragraph on. If all the targets the author currently envisions are GC'd languages, it's premature pessimization to worry about how other, hypothetical, targets might be accommodated. Aah. I should probably have clarified that. At Sanity.io today we only need JavaScript a…

Thanks for your response. You made your point more explicit, but I still think that being afraid of GC due to planning to support C at some point could be premature pessimization. Your milage obviously varies!

Also, yes, thank you for mentioning Parsing with Derivatives and all the other stuff, I really liked the overview you gave of the field.

Post reply on HN