Parsec parsers that are not implemented

[Marwes]

Below is a list of (hopefully) all the parsers which exist in parsec but not in this library. I added some comments on a few of them about their usefulness. If there is a parser you would argue for its inclusion (or exclusion) please leave a comment.

Parser combinators

option :: Stream s m t => a -> ParsecT s u m a -> ParsecT s u m a
optionMaybe :: Stream s m t => ParsecT s u m a -> ParsecT s u m (Maybe a)
optional :: Stream s m t => ParsecT s u m a -> ParsecT s u m ()

The 'optionMaybe' parser is called 'optional' in this lib which can cover all cases.

count :: Stream s m t => Int -> ParsecT s u m a -> ParsecT s u m [a]
endBy :: Stream s m t => ParsecT s u m a -> ParsecT s u m sep -> ParsecT s u m [a]
endBy1 :: Stream s m t => ParsecT s u m a -> ParsecT s u m sep -> ParsecT s u m [a]
chainl :: Stream s m t => ParsecT s u m a -> ParsecT s u m (a -> a -> a) -> a -> ParsecT s u m a
chainr :: Stream s m t => ParsecT s u m a -> ParsecT s u m (a -> a -> a) -> a -> ParsecT s u m a
manyTill :: Stream s m t => ParsecT s u m a -> ParsecT s u m end -> ParsecT s u m [a]
lookAhead :: Stream s m t => ParsecT s u m a -> ParsecT s u m a

Char parsers

oneOf :: Stream s m Char => [Char] -> ParsecT s u m Char
noneOf :: Stream s m Char => [Char] -> ParsecT s u m Char
endOfLine :: Stream s m Char => ParsecT s u m Char

satisfy covers all of these cases. These parsers could give better error reporting though which is an argument for their inclusion.

Added parsers:

newline :: Stream s m Char => ParsecT s u m Char
crlf :: Stream s m Char => ParsecT s u m Char
tab :: Stream s m Char => ParsecT s u m Char
upper :: Stream s m Char => ParsecT s u m Char
lower :: Stream s m Char => ParsecT s u m Char
alphaNum :: Stream s m Char => ParsecT s u m Char
letter :: Stream s m Char => ParsecT s u m Char
digit :: Stream s m Char => ParsecT s u m Char
hexDigit :: Stream s m Char => ParsecT s u m Char
octDigit :: Stream s m Char => ParsecT s u m Char

char :: Stream s m Char => Char -> ParsecT s u m Char

chainr1 :: Stream s m t => ParsecT s u m a -> ParsecT s u m (a -> a -> a) -> ParsecT s u m a
sepEndBy :: Stream s m t => ParsecT s u m a -> ParsecT s u m sep -> ParsecT s u m [a]
sepEndBy1 :: Stream s m t => ParsecT s u m a -> ParsecT s u m sep -> ParsecT s u m [a]

skipMany :: ParsecT s u m a -> ParsecT s u m ()
skipMany1 :: Stream s m t => ParsecT s u m a -> ParsecT s u m ()

Equivalent to many(parser.map(|_| ())) since the many parser should not allocate the vector for zero sized values.
Added since the above example will not compile without type annotations any longer and it is not obvious that it does not allocate any memory.

choice :: Stream s m t => [ParsecT s u m a] -> ParsecT s u m a

Added as choice_slice and choice_vec, might be generalized further later on.

anyToken :: (Stream s m t, Show t) => ParsecT s u m t

Added as the any parser.

eof :: (Stream s m t, Show t) => ParsecT s u m ()

Added as the eof parser.

[jxv]

WIth oneOf, noneOf, char, and count functions above. They take some non-parsec-transformer value as an arg to curry a new function with that value in its environment. Now, should there be way to generalize the capture with a struct and a function?

Take this gist for example:

// F: Fn(E,A,P) -> B
 struct Capture<E,A,B,P,F> {
    env: E,
    parser: P,
    func: F
}

[Marwes]

I sketched out something like the Capture struct when helping giving help in the reddit post. Still, I think the bigger issue is with the oneOf and nonOf functions of what type of argument they should take. With slices they are efficient but bound to a lifetime and a Vec forces allocation. The Cow type could allow for both but forces an additional overhead. I am not sure what is the best approach here.

[jxv]

In regards to the Cow type's overhead. (I don't know how much it has). Why not implement both approach but as separate structs/functions? Eg. OneOfVec/one_of_vec and OneOfSlice/one_of_slice.

[Marwes]

I think Cow should just be an extra 8 bytes for the tag (so 24 bytes for Vec + 8 = 32 bytes) vs 16 bytes for only a slice. I don't believe that there should be any branch overhead for the usage though, since the slice and Vec type both have their pointer and length at the same location in memory.

There is also the option of going even more generically by using some trait which can be implemented for any sort of collection though since the collection traits where removed from the standard library it is probably necessary to define it in the library which seems like overkill.

[tailhook]

It seems I need sepEndBy, because I'm tired of trailing comma issue. Is it hard to implement?

[Marwes]

It shouldn't be particularly hard to implement if feel free to give it a go if you want. If you look at the sepBy parser it should get you most of the way though it is a bit more complex than it needs to be. I can take a look later this week otherwise.

[Marwes]

sep_end_by and sep_end_by1 were added in 7ae8d32

[tailhook]

@Marwes works fine. Thanks a lot!

[Marwes]

eof added in 1.3.0

[Marwes]

Closing since all relevant parsers have presumably been added by now. If a parser is still missing then just open a new issue!