On Tue, Jun 30, 2009 at 06:24:57PM -0700, John Meacham wrote:
On Tue, Jun 30, 2009 at 04:58:13PM +0100, Ross Paterson wrote:
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.
The rules specified in this case are that the specialized version defines the same function as the default definition.
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.
Something doesn't add up here: things that don't terminate are not equal to things that do.
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'.
It's true that Alternative is loosely specified, requiring only a monoid, but it's still very useful (like MonadPlus). In my opinion, the compelling application is "Parsing Permutation Phrases", by Arthur Baars, Andres Loeh and S. Doaitse Swierstra, Haskell Workshop 2001 (see the action-permutations package). It does seem that your application doesn't fit the class, but it's not clear how dropping it would help.