Hi, I'm a big fan of literate haskell, especially Bird-style, but there's one behavior that I find rather annoying: the requirement that code be preceded and followed by a blank line. Quoth the Report: "To capture some cases where one omits an ">" by mistake, it is an error for a program line to appear adjacent to a non-blank comment line, where a line is taken as blank if it consists only of whitespace." While that is something I do anyway, since it looks better, there are some cases where it would be nice to relax that. For example: 1. I see a blog post in literate style, but the author did not provide a .lhs file, sometimes copying and pasting the text will result in code being adjacent to the text. Then I have to fix that manually. 2. It would be nice for prototyping if you could quickly comment out code just by removing a ">" character, instead of inserting "--". 3. Pandoc, via markdown, is a very interesting alternative to latex. Right now you can write a block of code like this: ~~~
fact :: Integer -> Integer fact 0 = 1 fact n = n * fact (n-1)
except that that won't work, precisely because you must have a blank
line before and after the code. Unfortunately, when you go and add
the blank lines, the output will show them. You may tell me to change
what Pandoc does, but my point is that getting any markup to work with
Bird-style will have this issue.
The only argument I can see for keeping the requirement is what the
report says, but feel free to provide others [1]. However, isn't that
a bit like saying "we will require two semicolons because forgetting a
semicolon is the number one source of mistake for our programmers"?
Besides, I suspect most of us uses an editor with syntax highlighting
(vi, emacs, yi, etc), and then it's immediately obvious you forgot
something.
Would it be hard to change this behavior in GHC? Is this open for
discussion for Haskell Prime?
Thanks,
Paulo
[1] I don't think it's that common to add a ">" by accident.
3. Pandoc, via markdown, is a very interesting alternative to latex. Right now you can write a block of code like this:
~~~
fact :: Integer -> Integer fact 0 = 1 fact n = n * fact (n-1)
except that that won't work, precisely because you must have a blank line before and after the code. Unfortunately, when you go and add the blank lines, the output will show them.
Note: I've changed pandoc in the repository so that it no longer shows these blank lines. The next point release will incorporate this change, making it easier to use pandoc for literate haskell. Note also that if you begin the code block with ~~~ {.haskell} the HTML output will be syntax-highlighted (assuming you compiled pandoc with the -fhighlighting flag). John
Hi John,
On Sun, Sep 21, 2008 at 3:33 PM, John MacFarlane
Note: I've changed pandoc in the repository so that it no longer shows these blank lines. The next point release will incorporate this change, making it easier to use pandoc for literate haskell. Note also that if you begin the code block with
~~~ {.haskell}
the HTML output will be syntax-highlighted (assuming you compiled pandoc with the -fhighlighting flag).
Thank you for taking care of that for us. I can check this in the code, but does this apply only to (leading and trailing) blank lines for haskell? I like the idea of automatically highlighting if it's available, it's working very well here. Paulo
Paulo Tanimoto wrote:
[1] I don't think it's that common to add a ">" by accident.
By intention, probably. But by accident it is a lot more common than you might think. Accidents like corrupting the linebreaks or line wrapping in a file are quite prevalent when exchanging files across different platforms or medium formats. Consider also file type misdetection with other languages like HTML; or more convincingly, consider language interleaving. And there're always garden variety typos like dropping a bird track or adding a space before it. Usually such corruption is easily captured by code not compiling, but I think the big thing to consider when suggesting changes to the .lhs format is how it affects the robustness of detecting file corruption, typos, etc. The whitespace restriction captures a goodly number of typos mentioned above, though it may not be so helpful for the other corruptions. -- Live well, ~wren
Hello Wren,
On Sun, Sep 21, 2008 at 10:02 PM, wren ng thornton
By intention, probably. But by accident it is a lot more common than you might think. Accidents like corrupting the linebreaks or line wrapping in a file are quite prevalent when exchanging files across different platforms or medium formats. Consider also file type misdetection with other languages like HTML; or more convincingly, consider language interleaving. And there're always garden variety typos like dropping a bird track or adding a space before it.
Usually such corruption is easily captured by code not compiling, but I think the big thing to consider when suggesting changes to the .lhs format is how it affects the robustness of detecting file corruption, typos, etc. The whitespace restriction captures a goodly number of typos mentioned above, though it may not be so helpful for the other corruptions.
Thanks for your thoughts. I see your point and I agree it's an important one. For example, as you well know, if you produce HTML with our Haskell libraries, there's some good chance you'll end up with a ">" mark in the beginning of the line, because of the way the tags are written. However, that's HTML. If you decide to interleave with other languages, I don't think the probability of having a ">" unexpectedly showing up in the beginning of the line is enough to justify making this a rule. In most languages it would be like writing a condition very close to the end of the line and having it break in the middle: if (x
y)
I think the restriction made sense when the report was written, but what I'm arguing is that given new developments we have made, the benefits of lifting the restriction are greater than keeping it. At least for me! : ) To be sure, I'm weighting the chances that the mandatory blank lines will save you versus the possibility of writing in Bird-style more freely. Again, please do point out other flaws in my argument. Thanks, Paulo
participants (3)
-
John MacFarlane -
Paulo Tanimoto -
wren ng thornton