<div dir="ltr">In the context of parsec, you'd probably behave as if you'd seen a closing brace (adjusting the generated AST accordingly) instead of actually inserting one. And likewise with respect to inserting semicolons. The spec isn't written in terms of that because it specifies effective behavior in terms of an unspecified parser design, instead of committing the implementor to a specific parser design.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 3:53 PM Benjamin Redelings <<a href="mailto:benjamin.redelings@gmail.com">benjamin.redelings@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Section 10.3 of the Haskell 2010 report describes the layout rule for <br>
Haskell in terms of rules for inserting curly braces and semicolons into <br>
the token stream.<br>
<br>
I'm not sure of the theory behind implementing Note 5 in section 10.3.  <br>
This says roughly that we insert a "}" token after token t[n] if the <br>
tokens t[1]...t[n+1] have no valid parses, and the sequence of tokens <br>
t[1] ... t[n] followed by "}" DO have a valid parse.<br>
<br>
I think this allows you to write<br>
<br>
f z = let x=2;y=3 in x+y+z<br>
<br>
However, except for Note 5, it seems like you could do a simple <br>
preprocessing step on the token stream to insert "{", ";", and "}" <br>
before parsing.  Note 5 seems more complicated.  (I feel like I read a <br>
note somewhere that said "read this and weep" and then failed to <br>
implement Note 5.  But now I can't remember where I read this.)<br>
<br>
In simple explanations like Write you a haskell <br>
(<a href="http://dev.stephendiehl.com/fun/008_extended_parser.html" rel="noreferrer" target="_blank">http://dev.stephendiehl.com/fun/008_extended_parser.html</a>) it seems that <br>
the approach is simply to ignore Note 5.<br>
<br>
Can anyone fill me in on<br>
<br>
(a) what concepts are assumed by the report that would make it "obvious" <br>
how Note 5 is supposed to be implemented?<br>
<br>
(b) a simple (hopefully) implementation strategy for implementing it? <br>
I'm looking for a language-independent approach for parsing.<br>
<br>
I did see some mention of error-correcting parsers in the Parsec paper, <br>
which might allow adding the "}" at a parse error.  But I see there is a <br>
paper called " An error correcting parser for context free grammars that <br>
takes less than cubic time".  The "less than cubic time" seems rather <br>
worrisome, so I don't know if this is the right approach.<br>
<br>
Also, when using parsec, it seems that you might get an idea how many <br>
tokens are a valid prefix of the grammer when the token stream fails to <br>
parse.  Hence, you could try inserting a "}" into the token stream at <br>
the point of a parse error.  However, a naive approach would then <br>
require re-parsing the whole stream from the beginning until each parse <br>
error, which seems very expensive.<br>
<br>
Thanks for any help!<br>
<br>
-BenRI<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>