[Haskell-cafe] bug in ghci ?
Edward Kmett
ekmett at gmail.com
Fri Jul 9 21:57:34 EDT 2010
On Fri, Jul 9, 2010 at 8:46 PM, Kevin Quick <quick at sparq.org> wrote:
> On Fri, 09 Jul 2010 16:26:13 -0700, Ivan Lazar Miljenovic <
> ivan.miljenovic at gmail.com> wrote:
>
> "Kevin Quick" <quick at sparq.org> writes:
>>
>> I would think that only mutually recursive default methods would
>>> require respecification and that there could be any number of default
>>> methods that were reasonable as is. Since it's probably quite
>>> difficult for the Haskell compiler to analytically detect
>>> non-terminating v.s. terminating mutual recursion it may be useful to
>>> define an explicit comment flag for this case.
>>>
>>> For example:
>>>
>>> class Show a where
>>> shows = showsPrec 5
>>> showsPrec _ = shows
>>> {-# REDEFINE_ONE: shows showsPrec #-}
>>>
>>> This would fairly simply allow a warning to be generated for an
>>> instance which did not redefine one of the identified methods; it
>>> would capture that requirement in the same place the recursive
>>> definition was defined, it would avoid false warnings, and it would be
>>> backward compatible (and it might be Haddock-able as well).
>>>
>>
>> This should be generalised IMO, since there might be cases where you
>> have to redefine either (foo && bar) || baz; of course, that makes the
>> syntax specification, etc. of the pragma more difficult...
>>
>
> I'm having trouble envisioning a restriction case such as you describe.
> Can you provide an example?
>
Examples:
class Bifunctor f where
bimap :: (a -> b) -> (c -> d) -> f a c -> f b d
first :: (a -> b) -> f a c -> f b c
second :: (a -> b) -> f c a -> f c b
first f = bimap f id
second = bimap id
bimap f g = second g . first f
{-# MUTUAL = first second | bimap #-}
The existing definition of Arrow is somewhat unsatisfying because its
product bifunctor definition (given by first, second and (***)) is
asymmetric. They choose to require you to define first, but could very well
use the same trick. (I am not advocating changing the well documented
historical definition of Arrow, just providing another example in the same
vein.)
class Category a => Arrow a where
arr :: (b -> c) -> a b c
first :: a b c -> a (b,d) (c,d)
second :: a b c -> a (d,b) (d,c)
(***) :: a b c -> a b' c' -> a (b,b') (c,c')
(&&&) :: a b c -> a b c' -> a b (c,c')
first = (*** id)
second = (id ***)
f *** g = first f >>> second g
f &&& g = arr (\b -> (b,b)) >>> f *** g
{-# MUTUAL first second | (***) #-}
An example that almost works would be Monad/Comonad where you can
define in terms of return/fmap/join or return/bind. However, the
definition of fmap is in another class, but if it wasn't:
class Comonad w where
liftW :: (a -> b) -> w a -> w b
extract :: w a -> a
extend :: (w a -> b) -> w a -> w b
duplicate :: w a -> w (w a)
extend = fmap f . duplicate
duplicate = extend id
{-# MUTUAL liftW duplicate | extend #-}
> The comment can't dictate that the resulting redefined method isn't still
> mutually recursive, but the warning for the lack of any override should
> provide enough of a trigger for the developer to read the docs/code and
> write an appropriate method. If foo, bar, and baz are all interrelated it
> seems to me that an appropriate override of any of them could provide the
> necessary exit from recursion.
>
It turns out to be fairly tricky to pull off the definition in such a way
that you can define any one combinator in turn of the others in a big long
cycle. Foldable does this for instance in such a way that foldMap and foldr
are defined cyclically.
That's probably an interesting assertion that one of the category theorists
> around here could prove or disprove. ;-)
>
I hope the above demonstrate that there are at least some fairly reasonable
(and, given your request, appropriately category theoretic!) examples where
one would want the ability to specify that there is more than one member of
a minimal mutual definition. =)
-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100709/77d38dc4/attachment.html
More information about the Haskell-Cafe
mailing list