StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>For your first example, you would replace </p> <pre><code>content = many anyChar </code></pre> <p>with</p> <pre><code>content = many digit </code></pre> <p>So that the parser of the content doesn't erroneously match the separator.</p> <p>Maybe you want to match more than just digits but even so, I advise you to think carefully about what <em>is</em> valid between <code><!></code>s and write a parser that does that. </p> <p><strong>Why?</strong><br> Once you've got a really good parser for content, your definition for response will be perfect. This way your content can include <code>mystring = "hello<!>mum"</code> without being chopped by the top level parser - the low level <code>stringLiteral</code> parser will eat the whole <code>"hello<!>mum"</code> and the top level parser will never see the <code><!></code> correctly and innocently included inside it.</p> <p><strong>Generally,...</strong><br> In most parsing situations it's best to be really clear what's allowed in your content, and parse only that, for three reasons: </p> <ul> <li>reusability (you can then use this within a larger parser)</li> <li>correctness</li> <li>usually efficiency - if you avoid too much lookahead, your parser runs faster.</li> </ul> <p>Reusability is important. At the moment, if you use a parser that just splits on <code><!></code> and eats everything else, it's guaranteed to eat the whole input, and you won't be able to do any more parsing.</p> <p><strong>Bottom-up</strong><br> Your parsers should work from the ground up - you described this very well in your comment as "stacking the parsers from specific to general". </p> <p>It's easiest to write them in that order for ease of testing, so first write one that matches a <code>stringChar</code> then <code>stringLiteral</code> before <code>member</code> before <code>array</code> before <code>object</code> before <code>json</code> before <code>content</code> then <code>response</code>. You can have them calling each other recursively along the way. You can then use <code>parseTest</code> to test each little one as you do along; typing <code>parseTest response "1<!>2<!>3"</code> into ghci is quicker than rewriting main and compiling.</p> <p><strong>Top-down?</strong><br> It's not wrong to write your parser top-down, just harder. You can write </p> <pre><code>response = many $ content `sepBy` contentSeparator content = json <|> somethingElse json = object <|> array array = ... </code></pre> <p>but nothing is testable until you've written the very smallest parser.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload