Hello, Sorry, I should have mentioned the origin of the combinators. These are (generalizations of) standard parser combinators, so think of "f a" in the type as a parser that can construct values of type "a". With this in mind, it should be more obvious what these combinators are used for. For example:

p `sepBy` sep is a parser that will return 0 or more occurances of 'p' separated by 'sep'. Many (all?) parser combinator libraries provide these functions, so having the generic 'Alternative' interface makes it easier to write parser that can work with different libraries. -Iavor

On Jan 6, 2008 3:34 PM, Seth Kurtzberg wrote:

Can you show some code fragments demonstrating how the combinators are used? I find it easier to understand the underlying concepts when I have not only the signature and implementation but an example of a typical use. It doesn't have to be working code, and it might even be pseudo code. (I'm not sure whether other Haskell folks feel the same way.)

On Sun, 6 Jan 2008 13:35:41 -0800 "Iavor Diatchki" wrote:

...

Hello, I propose that we add the following combinators to the 'Control.Applicative' module:

skipMany :: (Alternative f) => f a -> f () skipMany p = skipSome p <|> pure ()

skipSome :: (Alternative f) => f a -> f () skipSome p = p *> skipMany p

endBy :: (Alternative f) => f a -> f b -> f [a] endBy p s = many (p <* s)

endBy1 :: (Alternative f) => f a -> f b -> f [a] endBy1 p s = some (p <* s)

sepBy :: (Alternative f) => f a -> f v -> f [a] sepBy p s = sepBy1 p s <|> pure []

sepBy1 :: (Alternative f) => f a -> f v -> f [a] sepBy1 p s = (:) <$> p <*> many (s *> p)

Any objections? Deadline for discussion is 2 weeks from now, which would be the 20th of Jan.

-Iavor _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Seth Kurtzberg Hardware/Software/Driver Engineering

Hello, On Jan 6, 2008 9:20 PM, Bryan O'Sullivan wrote:

While applicative functors are good for this task, it would be a shame if the innocent reader of haddocks were to acquire the impression that parsing was all they were for.

:-) oh, come on! I was just giving an example of what these combinators may be used for. They are not any more related to parsing than say, 'many', 'some', or 'empty' and '(<|>)'---they provide just a few more useful control structures.

Why not make the task specificity clearer, with a separate Control.Applicative.Parsing module?

Now _this_ would definitely suggest that they are only good for parsing which would be misleading. -Iavor

On Mon, Jan 07, 2008 at 04:53:14PM -0800, Don Stewart wrote:

iavor.diatchki:

...

Hello,

On Jan 6, 2008 9:20 PM, Bryan O'Sullivan wrote:

...

While applicative functors are good for this task, it would be a shame if the innocent reader of haddocks were to acquire the impression that parsing was all they were for.

:-) oh, come on! I was just giving an example of what these combinators may be used for. They are not any more related to parsing than say, 'many', 'some', or 'empty' and '(<|>)'---they provide just a few more useful control structures.

...

Why not make the task specificity clearer, with a separate Control.Applicative.Parsing module?

Now _this_ would definitely suggest that they are only good for parsing which would be misleading.

+1 for this proposal. Glue for combining parsers seems like a missing piece. Perhaps toss in an example in the docs?

Actually, there is a major issue with the current 'many', 'some' etc functions in Applicative. They arn't actually useful for applicative but non-monadic parsers! in fact, they lead to infinite loops! This is quite disturbing as statically analyzed parsers were part of the motivation of splitting out applicative. The reason is that it 'hides' the self-referential nature of the function in the recursive call directly so any routine attempting to analyze the parser will go around in circles. I think the solution would be either to get rid of many, etc.. or make them members of the type class. It is not even clear to me that just because something is a member of 'Alternative' that it has a natural, meaningful notion of repetition, so perhaps they belong in their own class. John -- John Meacham - ⑆repetae.net⑆john⑈

Hello, On Jan 8, 2008 1:43 AM, apfelmus wrote:

Iavor Diatchki wrote:

...

Bryan O'Sullivan wrote:

...

Why not make the task specificity clearer, with a separate Control.Applicative.Parsing module?

+1

...

Now _this_ would definitely suggest that they are only good for parsing which would be misleading.

Would it? I mean, I currently don't know a second use case for them. Preferably, the names like skipMany , endBy , sepBy etc. should still make sense in the new context.

Yes it would. The name Control.Applicative.Parsing certainly suggests that. We should not overdo the granularity of the modules in the library. What would be the benefit of having a separate module? By the way, the combinators are all variations of 'many': 'skipMany' is just like 'many' but ignoring the results; 'endBy' performs a "cleanup" computation after each iteration; "sepBy" performs a "cleanup" operation between iterations. As I said before, these are just ordinary control structures. -Iavor