Re: PROPOSAL: Some more 'Applicative' combinators

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⑈