Eliminate/move class Alternative
ben.franksen at online.de
Mon May 4 18:09:43 EDT 2009
Martijn van Steenbergen wrote:
> Ben Franksen wrote:
>> I was refering to the 1996 paper titled "Deterministic, Error-Correcting
>> Combinator Parsers", where the 'fail' parser needs extra arguments. Maybe
>> I am dense, but I can't see how to avoid the arguments w/o constraining
>> the type of the result (which would mean the parsers can't even be
>> instances of Applicative).
> The trick is to not constrain the result type: pFail should be
> polymorphic in its result type. Suppose you use the list of successes
>> type Parser s a = [s] -> [(a, [s])]
> Then pFail may be defined as:
>> pFail :: Parser s a
>> pFail = const 
> i.e. polymorphic in output (and input too), because  :: [a] is
> polymorphic in its element type.
I never claimed that _no_ parser combinator library can offer pFail :: p
a ; indeed, most do. The problem I see is when parsers are supposed to be
error-correcting, particularly if this means they should never fail to
produce a result. (A parser of the 'list of successes' type can not have
this property, because  means 'no result'.) And now the question is how
some pFail :: p a can conjure up a result value if the result type a is
not constrained (e.g. to have a 'default' element).
The other problem is good error messages. For instance, although Parsec has
parserZero :: (Monad m) => ParsecT s u m a
it is defined thus (in version 3.0.0):
= ParsecT $ \s -> return $ Empty $ return $ Error (unknownError s)
that is, you'll get no usable error message. Fortunately, for practical use
parserFail :: (Monad m) => String -> ParsecT s u m a
and this requires an extra argument.
More information about the Libraries