Re: [Haskell-cafe] bug in ghci ?

9 Jul 2010

      On Fri, Jul 9, 2010 at 8:46 PM, Kevin Quick  wrote:
...
On Fri, 09 Jul 2010 16:26:13 -0700, Ivan Lazar Miljenovic <
ivan.miljenovic@gmail.com> wrote:
"Kevin Quick"  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