<div dir="auto">Where clauses are not *always* attached to definitions. They can also be attached to case branches.<div dir="auto"><br></div><div dir="auto">case z of</div><div dir="auto">  Just n -> blah</div><div dir="auto">    where blah = n * 7</div><div dir="auto"><br></div><div dir="auto">What I believe is true is that anywhere a set of guards could occur, they may be followed by a where clause, and vice versa.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sep 9, 2017 12:08 AM, "Alexis King" <<a href="mailto:lexi.lambda@gmail.com">lexi.lambda@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No, it isn’t a GHC parser error.<br>
<br>
Your preceding expression ends in a where clause, like this:<br>
<br>
   assertBool "4" $ p == Right a where<br>
       p = ...<br>
<br>
That’s fine, but make sure you understand how where works. Where clauses<br>
are not attached to individual expressions, they are *always* attached<br>
to definitions. In this case, the where clause is not attached to the<br>
assertion but to your definition of tHash. GHC parses your program the<br>
same way as this one:<br>
<br>
    tHash = TestCase $ do<br>
        ...<br>
        assertBool "4" $ p == Right a<br>
      where<br>
        p = ...<br>
<br>
Therefore, the where clause forces the termination of the do block,<br>
since it exists syntactically outside the “body” of a definition. It is<br>
its own syntactic construct, an optional sequence of definitions in<br>
scope within the RHS of a definition. You cannot have any more<br>
expression after the where clause because they would be free-floating,<br>
outside of any particular definition.<br>
<br>
If you really want definitions that are scoped to that single assertion,<br>
use a let expression instead of a where clause:<br>
<br>
    let p = ...<br>
        a = ...<br>
    in assertBool "4" $ p == Right a<br>
<br>
That works, since let...in blocks serve as completely ordinary<br>
expressions, and they are permitted anywhere an expression is permitted<br>
(unlike where clauses, which must “belong” to a top-level or let-bound<br>
definition).<br>
<br>
> On Sep 8, 2017, at 20:54, Jeffrey Brown <<a href="mailto:jeffbrown.the@gmail.com">jeffbrown.the@gmail.com</a>><br>
> wrote:<br>
><br>
> The test suite below[1] does what it's supposed to. The last line of<br>
> it is a commented-out test case:<br>
><br>
>     -- assertBool "broken" $ True<br>
><br>
> If I uncomment that, it fails to compile:<br>
><br>
>     > :reload<br>
>     [13 of 13] Compiling TParse           ( test/TParse.hs, interpreted )<br>
><br>
>     test/TParse.hs:67:3: error: parse error on input ‘assertBool’<br>
>        |<br>
>     67 |   assertBool "broken" $ True<br>
>        |   ^^^^^^^^^^<br>
>     Failed, 12 modules loaded.<br>
>     ><br>
><br>
> However, if I move it to somewhere earlier in the code, it works.<br>
><br>
><br>
> [1] <a href="https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/e5afd39b950752ccb65997b89ab625d859299b4a/test/TParse.hs" rel="noreferrer" target="_blank">https://github.com/<wbr>JeffreyBenjaminBrown/digraphs-<wbr>with-text/blob/<wbr>e5afd39b950752ccb65997b89ab625<wbr>d859299b4a/test/TParse.hs</a><br>
><br>
> Jeff Brown | Jeffrey Benjamin Brown<br>
<br>
______________________________<wbr>_________________<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-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div>