After some thinking I decided that this may be not desirable in some
cases, so we should not enable it by default. I've edited documentation
of ‘makeExprParser’ to explain why this doesn't work by default and how
to make it work.
Close#64.
‘makeExprParser’ now generates parser that can handle several
occurrences of the same prefix or postfix operator in a row. This allows
to parse something like C pointers (for example ‘**i’) without resorting
to hacks.
The feature is experimental, I'm not entirely sure it's not
buggy. Upcoming additional tests for ‘Text.Megaparsec.Expr’ will show
whether it behaves correctly in all cases and doesn't have adverse
effects. For now, I've edited existing test to generate data with
repeating prefix negations and postfix factorials. Current code-base
passes the test.
Close#69.
Although previously used syntax is correct Haskell syntax for multi-line
string literals, CPP extension that we need to use for compatibility
reasons obviously makes ‘\’ symbol escape following newline character
that leads to ‘\t’ being interpreted as tab character.
The proposed solution just concatenates result error message from list
of strings — the most lightweight and reliable solution in our case.
What Parsec used is called “FreeBSD” or “BSD 2 clause”. Addition of the
third clause may require contacting all the authors. To hell with it,
let it be “FreeBSD” (which is anyway better than “BSD-like”), I'm a
hacker, not a lawyer (tm).
This commit clarifies license of the software replacing “BSD3” with more
conventional “BSD 3 clause”.
Another change is addition of the third clause originally missing in
license of Parsec (which is licensed under BSD 2 clause license). The
addition of the third clause in form:
* Neither the names of the copyright holders nor the names of
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
does not violate original BSD 2 clause license effectively making it BSD
3 clause license (which I find preferable).
Close#43.
The method allows to fail with arbitrary collection of
messages. ‘unexpected’ is not defined in terms of ‘failure’. One
consequence of this design decision is that ‘failure’ is now method of
‘MonadParsec’, while ‘unexpected’ is not.
Close#47, close#57.
This commit introduces ‘runParser'’ and ‘runParserT'’ functions that
take and return parser state. This makes it possible to partially parse
input, resume parsing, specify non-standard initial textual position,
etc.
Internal changes involve some refactoring to make ‘Reply’ more
readable and facilitate extraction of complete parser state on failure
as well as success.
The commit adds basic tests for the new functionality as well.
Close#65.
Previously we had 5 nearly identical definitions of the function,
varying only in type-specific ‘readFile’ function. Now the problem is
solved by introduction of ‘StorableStream’ type class. All supported
stream types are instances of the class out of box and thus we have
polymorphic version of ‘parseFromFile’.
Close#62.
Apart from some refactoring, the following important changes were
introduced:
* ‘ParseError’ is now a monoid.
* Added functions ‘addErrorMessages’ and ‘newErrorMessages’.
Now it's impossible to create ‘SourcePos’ with non-positive line number
or column number. Unfortunately we cannot use ‘Numeric.Natural’ because
we need to support older versions of ‘base’.
It seems like there won't be official Megaparsec tutorial for a
while. Also, the text is now written in such manner so it can be used on
Megaparsec site without any additional corrections.
This commit mainly adds missing "a", "an" or "the", whenever something is used in singular, for example:
- user will see the label in error message
+ the user will see the label in the error message
In some cases, I've removed a word, for example "module" after `Text.Megaparsec.Char`, since it's clear you're talking about a module (otherwise "the" before the module name would be necessary).
This should provide a more fluid reading experience.
Indented text returned by ‘showMessages’ may be undesirable, but we
cannot add indentation outside of the function (edge case: strings
including newline are displayed in the messages).
