Eliminate/move class Alternative

[Ben Franksen]

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
> parser:
> 
>> 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
a

  parserZero :: (Monad m) => ParsecT s u m a

it is defined thus (in version 3.0.0):

  parserZero
    = ParsecT $ \s -> return $ Empty $ return $ Error (unknownError s)

that is, you'll get no usable error message. Fortunately, for practical use
there is

  parserFail :: (Monad m) => String -> ParsecT s u m a

and this requires an extra argument.

Cheers
Ben