The framing in this page is broken on Firefox Android. The last couple of lines can't be scrolled into view.
Just Write the Parser
41–50 of 85 posts
Re: Just Write the Parser
#42An alternate title: "Just Shotgun Parse Your Inputs". This isn't bad advice across the board , but it is bad advice for many applications. This is how you end up with context-sensitive formats, or ones where the semantics of a particular particle require running the parser, or worse. It exposes a rich surface area for exploitation with adversarial inputs. That said, the advantages cited at the front of the article ar…
I agree with everything you say, except your advice to use a parser combinator library, because most implement PEGs. Hammer is, of course, an exception to this, as long as you call `h_compile` to tell it to use a different backend. Why not use PEGs? In short, they don't actually remove ambiguity from your grammar, but rather hide it in ways that are difficult to reason about. You're still dependent on code as a defin…
I firmly disagree about the value of PEGs (and hence combinators) as a formalism that's ambiguous or hard to reason about. PEGs are as well-specified as CFGs, they just work in a different way. One of the strengths of PEGs is that they're never ambiguous. That does mean that order of alternates is important, and sometimes you do have to fiddle with that order when translating something like ABNF. But what you get in return is never having to deal with a parse forest, let alone punting on that problem by just reifying the greedy parse as the correct one.
I've written a tool that converts a declarative specification of a PEG grammar into a parser, although I haven't released it yet. It works great, I've used it on a number of real-world structured data formats.
Edit: cut out the first paragraph after checking the user name. Hi TQ.
Re: Just Write the Parser
#43An alternate title: "Just Shotgun Parse Your Inputs". This isn't bad advice across the board , but it is bad advice for many applications. This is how you end up with context-sensitive formats, or ones where the semantics of a particular particle require running the parser, or worse. It exposes a rich surface area for exploitation with adversarial inputs. That said, the advantages cited at the front of the article ar…
I agree with everything you say, except your advice to use a parser combinator library, because most implement PEGs. Hammer is, of course, an exception to this, as long as you call `h_compile` to tell it to use a different backend. Why not use PEGs? In short, they don't actually remove ambiguity from your grammar, but rather hide it in ways that are difficult to reason about. You're still dependent on code as a defin…
In my experience LPeg does a good job of being comprehensible for most reasonably-sized use cases. It can even parse the grammar of Lua itself. I've personally had not that much trouble translating BNF grammars to PEG, though the result is typically longer. It still satisfies the goal of separating parsing logic from data logic, which is a big step.
For more info on the issues with PEGs -- and a paper showing how to correctly translate general LL(1p) grammars to PEG -- see:
https://jeffreykegler.github.io/Ocean-of-Awareness-blog/indi...
Re: Just Write the Parser
#44Earlier quoted context omitted.
Yeah I think something is broken because at least in chrome when you try to type in the left box the following exception keeps being thrown in the console VM463:82 Uncaught TypeError: Cannot read property 'startContainer' of undefined at HTMLPreElement.eval (eval at run (eval at runScriptElement (octopus-2.js:525)), :82:40)
I just pushed a fix for Chrome (apparently it doesn't report affected selection ranges for input events). Hope it works now!
I can't type on the left in Firefox still. Using 81.0.2.
Re: Just Write the Parser
#45A long time ago I did a deep-dive on recursive descent parsing and ended up writing a parser generator [1].
[1] https://github.com/reindeereffect/tools-from-blog/tree/maste...
Re: Just Write the Parser
#46I find it handy to write out the grammar for a parser generator to check for problems, then handwrite the parser once it passes.
Re: Just Write the Parser
#47Author here - happy to answer questions, as always. Thanks also for feedback on the format of the article. It's a bit of an experiment on how to present dense information effectively. Some more rationale here: https://tiarkrompf.github.io/notes/?/octopus-notes/
What's the best way to handle unary "-" and other unary operators? I'd like to be able to write expressions like "-2^-(2+2)" or "a cos b + a sin b". For "-2^-(2+2)" note that exponentiation has higher precedence than negation.
Take the current + next node
i.e: parse_node + parse_peek
When parse_node is an operator you know it is the "-2" in "-2^-2(2+2)" and when parse_peek is the operator it is "-(2+2)" in the same. An example of this:
- https://github.com/thysultan/Ally/blob/8ba0b4de7ab104ceae54d...
Re: Just Write the Parser
#48Earlier quoted context omitted.
I think the design is great. Simple and easy to read.
I'm not quite sure why they went with the borked "half the screen is empty" look. Ok, it's easier to read, but that negative space is bad design, regardless.
I found the design to be very intuitive even though I'd never encountered that type of information flow before. The curly braces didn't seem to serve any purpose as far as I could tell, but the negative space was great. I knew exactly where the content was going to pop up before I clicked the "link". No jarring resize, just plain ole empty space not taking your attention away from the main content until you want see content in there.
Re: Just Write the Parser
#49Earlier quoted context omitted.
I think the design is great. Simple and easy to read.
I'm not quite sure why they went with the borked "half the screen is empty" look. Ok, it's easier to read, but that negative space is bad design, regardless.
Because... ? https://megous.com/dl/tmp/da01875b777013e9.png
Re: Just Write the Parser
#50Author here - happy to answer questions, as always. Thanks also for feedback on the format of the article. It's a bit of an experiment on how to present dense information effectively. Some more rationale here: https://tiarkrompf.github.io/notes/?/octopus-notes/
What's the best way to handle unary "-" and other unary operators? I'd like to be able to write expressions like "-2^-(2+2)" or "a cos b + a sin b". For "-2^-(2+2)" note that exponentiation has higher precedence than negation.
[deleted]