Interplay of >>> and prop>

[sgraf812]

Consider this:

-- |
-- >>> let x = 1
-- prop> x == 1
main = putStrLn "Hello World"

This complains that the output of let x = 1 didn't match prop> x == 1. If the prop> were a >>> instead, this would at least pass the first line (independent of #174, which would happen the line after).

[andreasabel]

Thanks for reporting. It is not entirely clear what feature you are requesting here. Could you elaborate more, e.g. on the expected behavior?

[sgraf812]

The line after >>> is always parsed as expected output (as long as it doesn't start with >>>). So, currently the above doctest states that the assignment let x = 1 should output the string prop> x == 1, which of course it doesn't.

This is rather surprising behavior, I rather expected that the second line would declare an ordinary quickcheck property.

A workaround is to insert an empty line inbetween, as in #174.

[sol]

I think this is an extension of #174. As we currently don't share the scope between properties and examples, code like

-- >>> let x = 1
-- prop> x == 1

is not something you commonly want to write.

@sgraf812 can you check what haddock does here. If haddock parses this as an example and a property then we want to do the same in doctest.

[sgraf812]

Judging from this function, haddock will most likely parse this as example + result. That makes no observable difference for haddock, I think, because results and properties are formatted the same. It does to doctest, though.

Maybe we should fix haddock first (e.g. add a property case to resultAndMoreExamples)? Also, wouldn't it make sense for doctest to depend on the haddock parser directly if we keep compatibility between the two anyway?

[amigalemming]

The problem might be solved by multi-line properties: #131.