If ‘x’ in ‘x >>= y’ consumes input but produces some hints, we should
accumulate them nonetheless. Why it's important can be demonstrated by
the following test:
many (char 'a') >> many (char 'b') >> eof
This should fail on input "ac" with the following message:
parse error at line 1, column 2:
unexpected 'c'
expecting 'a', 'b' or end of input
As you can see even though parser ‘many (char 'a')’ consumed input, its
hits may be useful later.
* Removed ‘optionMaybe’ parser, because ‘optional’ from
‘Control.Applicative’ does the same thing.
* Renamed ‘tokenPrim’ → ‘token’, removed old ‘token’, because
‘tokenPrim’ is more general and ‘token’ is little used.
* Fixed bug with ‘notFollowedBy’ always succeeded with parsers that
don't consume input, see #6.
* Hint system introduced that greatly improved quality of error messages
and made code of ‘Text.Megaparsec.Prim’ a lot clearer.
The improvements affected other modules too:
* Some parsers from ‘Text.Megaparsec.Combinators’ now live in
‘Text.Megaparsec.Prim’.
* Hint system improved error messages, so I needed to rewrite test for
‘Text.Megaparsec.Char.eol’, since it's error messages are very
intelligent now and cannot be emulated by ‘newline’ and ‘crlf’ parsers
used separately.
* Test for Bug9 from old-tests is passed successfully again.
This parser can be told to parse from ‘m’ to ‘n’ occurrences of some
thing. Old parser ‘count’ is now named ‘count’' and defined in terms of
that more powerful one.
This commit also reorders functions in module
‘Text.Megaparsec.Combinator’ and everywhere where the functions are
listed. The same order is used everywhere.
Added new character parsers in ‘Text.Megaparsec.Char’:
* ‘controlChar’
* ‘printChar’
* ‘markChar’
* ‘numberChar’
* ‘punctuationChar’
* ‘symbolChar’
* ‘separatorChar’
* ‘asciiChar’
* ‘latin1Char’
* ‘charCategory’
Renamed some parsers:
‘spaces’ → ‘space’
‘space’ → ‘spaceChar’
‘lower’ → ‘lowerChar’
‘upper’ → ‘upperChar’
‘letter’ → ‘letterChar’
‘alphaNum’ → ‘alphaNumChar’
‘digit’ → ‘digitChar’
‘octDigit’ → ‘octDigitChar’
‘hexDigit’ → ‘hexDigitChar’
Descriptions of old parsers have been updated to accent some
Unicode-specific moments. For example, old description of ‘letter’
stated that it parses letters from “a” to “z” and from “A” to “Z”. This
is wrong, since it used ‘Data.Char.isAlpha’ predicate internally and
thus parsed many more characters.
New tests shows that I had wrong assumption about workings of this
particular function. This is not a problem, though, complete test-suite
will eliminate this sort of nuisance soon.
These functions are now re-exported from ‘Control.Applicative’
module. ‘many’ and ‘some’ are now part of ‘Alternative’ instance of
‘ParsecT’.
Note that these functions are re-exported only in ‘Text.MegaParsec’
module, but not in ‘Text.MegaParsec.Prim’ to avoid duplication of
floating doc-strings. Others internal modules now just casually import
‘Control.Applicative’ for their needs.
Note that ‘many1’ was renamed to ‘some’, the same is done for other
parsers that had ‘many1’ part in their names (for consistency).
Changed how numbers are parsed because they were parsed in a naïf and
hairy way. Added tests for #2 and #3 (in old Parsec project these are
number 35 and 39 respectively).
* Since Haskell report doesn't say anything about sign, I've made
‘integer’ and ‘float’ parse numbers without sign.
* Removed ‘natural’ parser, it's equal to new ‘integer’ now.
* Renamed ‘naturalOrFloat’ → ‘number’ — this doesn't parse sign too.
* Added new combinator ‘signed’ to parse all sorts of signed numbers.
* For the sake of convenience I've added ‘integer'’, ‘float'’, and
‘number'’ combinators that also can parse signed numbers out of box.
Example
Before:
Prelude Text.Parsec> parseTest (string "abcd") "abbe"
parse error at (line 1, column 1):
unexpected "b"
expecting "abcd"
After:
*Main> parseTest (string "abcd") "abbe"
parse error at (line 1, column 3):
unexpected "b"
expecting "cd"
Before this patch, 'b' was reported to be found at 1:1, which is clearly not the
case. After this patch, we correctly report the location of the wrong token, and
also report missing tokens starting from that position.
This fixes a regression introduced by:
Sun Feb 20 18:24:22 EET 2011 Roman Cheplyaka <roma@ro-che.info>
* Choose the longest match when merging error messages
The source of the regression is that parsec sometimes generates dummy (aka
"unknown") error messages when no actual error has occurred.
So, when merging errors, before simply looking at the positions we should check
if one of them is unknown and just ignore it.
Reported by Matthias Hörmann.
