[Haskell-cafe] Splitting off many/some from Alternative

[Antoine Latter]

On Mon, Dec 12, 2011 at 4:30 PM, John Meacham <john at repetae.net> wrote:
> Yes, they are major pains for frisby, which is a parser but needs to
> be cleverer about recursion, the many and some that come with
> applicative actually cause infinite loops.
>

That's why 'many' and 'some' were promoted up to being class methods,
so that folks that needed a more specific implementation could provide
one.

But now they look as if they are of equal importance with the other
class methods, which is not really true.

Antoine

>    John
>
> On Sun, Dec 11, 2011 at 9:18 PM, Gregory Crosswhite
> <gcrosswhite at gmail.com> wrote:
>> Hey everyone,
>>
>> I am sure that it is too late to do more than idly speculate about this, but
>> could we split the some/many methods out from Alternative?  They simply
>> don't make sense except in a subset of possible Alternatives --- in most
>> cases they just result in an infinite loop.  That is to say, it is not just
>> that they are extraneous functionality, but most of the time they are
>> *impossible* functionality to even implement!  In a way, it is a lie to be
>> including them in Alternative since people making use of the class might
>> incorrectly (but quite reasonably!) assume that any type that is an instance
>> of Alternative *has* a well-defined some and many method, when this is
>> actually the exception rather than the rule.
>>
>> It is only recently that I have been able to grok what some and many are
>> even about (I think), and they seem to only make sense in cases where
>> executing the Alternative action results in a portion of some input being
>> consumed or not consumed.  "some v" means "consume at least one v and return
>> the list of items consumed or fail", and "many v" means "consume zero or
>> more v and return the list of items consumed or the empty list of none are
>> consume".  It thus makes sense for there to be some subclass of Alternative
>> called something like "Consumptive" that contains these methods.  The
>> majority of "Alternative" instances would no longer have these methods, and
>> again that would actually be an improvement since in such cases some/many
>> were unworkable and did nothing but cause infinite loops anyway.
>>
>> Normally it would be unthinkable to even consider such a change to the base
>> libraries, but I suspect that there are not more than a couple of packages
>> out there that make active use of the some/many instances of Alternative;
>>  it is really only parser packages that need some/many, and users most
>> likely use the versions included with the packages themselves rather than
>> the Alternative version.  Could we verify that this is the case, and if so
>> split them away?  I thought I heard a trick whereby people were able to grep
>> all the source on Hackage, but I can't remember what it was.  :-)
>>
>> Just a thought.  :-)
>>
>> Thanks,
>> Greg
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe