On Tue, Jun 30, 2009 at 04:58:13PM +0100, Ross Paterson wrote:
On Tue, Jun 30, 2009 at 11:45:50AM -0400, Edward Kmett wrote:
I've been burned by this myself as well. I also have a set of parser combinators that I've been working on that could currently greatly benefit from these asymptotically in some places and in the case of a bottom up monoidal parser I've been working with, the availability of these makes the difference between termination and non-termination in some cases.
Ah, but that's changing the meaning, which isn't what these are supposed to be for.
I don't see why not. As long as your versions follow whatever rules are specified for the class. frisby also cannot use Applicative as is because these methods arn't able to be overridden and the default implementations lead to pessimal (to the point of unusabality, or even non-termination) performance. However frisby can provide perfectly valid implementations of them that follow the Applicative laws and have no such issues. Actually, 'Alternative' doesn't have any rules as to its meaning, which is probably why the broken 'many' and 'some' ended up there in the first place. Personally, I'd prefer just to drop 'many' and 'some' (and perhaps 'Alternative' itself) completely since it isn't clear meaningful definitions exist for what we might consider members of 'Alternative'. But making them members of the class is an acceptable compromise if people don't want to drop Alternative. Without a clear meaning, it is basically just a syntax reuse class. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/