PROPOSAL: Some more 'Applicative' combinators

[John Meacham]

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 <bos at serpentine.com> 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⑈