On Thu, 08 Jul 2010 09:48:34 -0700, Daniel Fischer <[email protected]>
wrote:
On Thursday 08 July 2010 18:24:05, Ben Millwood wrote:
On Thu, Jul 8, 2010 at 3:45 PM, Daniel Fischer <[email protected]>
wrote:
> Well, I made the suggestion of emitting a warning on instance
> declarations without method definitions. That would be comparatively
> easy to implement (even with an additional check to only emit the
> warning if the class defines any methods) and catch many (if not most)
> cases.
Unfortunately, it would catch some perfectly valid cases, see the list
of instances for flat datatypes here:
http://hackage.haskell.org/packages/archive/deepseq/1.1.0.0/doc/html/src
/Control-DeepSeq.html
This demonstrates that there is at least one (admittedly probably not
much more than one) case where a class with methods would have a
default implementation that was total and valid in some cases.
Good point.
So one should check for more than one class-method [then defining no
methods in the instance declaration is likely to lead to a default-method
loop if there are default methods for all, otherwise GHC will warn
already].
That can of course still give rise to spurious warnings, but is less likely
to.
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).
--
-KQ
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
