Support for CRLF line breaks

[Daniel-Diaz]

I - as many others - write parsers that run on different systems. Windows uses CRLF line breaks while Unix uses just LF. Currently, the newline parser only succeeds for LF line breaks. This leads to parsers that fail on one system but not the other, which is annoying.

In my software, I frequently add the parsers I have attached in this pull request. I thought that they may be useful for other users of parsec. Basically, I am just adding CRLF line break support and a anyNewline parser, which succeeds for both LF and CRLF line breaks.

If there is any concern about the names, they can be modified.

[aslatter]

How are you getting your strings into your parser?

For some reason I was under the impression that some of the file-IO APIs did some normalization of newlines.

[UnkindPartition]

Text IO (openFile, Data.Text) indeed performs newline conversion.
Binary IO (openBinaryFile, Data.ByteString) doesn't.

[Daniel-Diaz]

I read files as ByteStrings and then I use a decoding function (like decodeLatin1 or decodeUtf8) to turn it into Text. The decoding function varies on each case.

[aslatter]

It's a pity that newline has a return-value. Otherwise we could re-define newline as newline = (char '\n' >> return ()) <|> (string "\r\n" >> return ()) <?> "new-line"

[aslatter]

Alright, after thinking for a bit it seems like we could either:

1. Re-define the type of newline
2. Steal endOfLine from attoparsec with the definition we'd like to have for newline

Option (1) might break people so I'm leaning towards (2) (even though I have no data).

[Daniel-Diaz]

I think very few people use the value returned by newline. In any case, I'd rather avoid option 1 since it may cause some breakages. So, yes, I would take option 2 as well.

[Daniel-Diaz]

Actually, some people may be using newline in a parser that reads a text with line breaks and keeps the text as it is after parsing. Something like:

parseSomeText :: Parser String
parseSomeText = many $ alphaNum <|> char ' ' <|> newline

So I take back that the very few people use the value returned by newline. I might be wrong there. Even more, I am probably doing it somewhere!

[Daniel-Diaz]

I have renamed anyNewline to endOfLine to adapt this pull request to (2). Any other changes needed?