RFC: Can DefaultSignature compile-time conditional APIs be regarded "benign"?

José Pedro Magalhães jpm at cs.uu.nl
Mon Nov 12 10:27:17 CET 2012


Hi,

I would prefer it if packages would use DefaultSignatures conditionally,
instead of creating new packages just to define a generic variant of a
function. In general, though, I think it's good practice to define the
defaults as separate functions (like `genericSize`) and export them, so
that those not using DefaultSignatures can still write an instance easily.

As for the concerns about people using DefaultSignatures and not realizing
their code is not portable, I guess we could reject programs that use a
default signature (when writing an empty instance) unless they enable
-XDefaultSignatures. Then people would know they are relying on an
extension.


Cheers,
Pedro


On Sun, Nov 11, 2012 at 9:06 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> Henning Thielemann <lemming at henning-thielemann.de> writes:
> > On Sun, 11 Nov 2012, Herbert Valerio Riedel wrote:
> >> E.g. consider the following hypothetical class definition:
> >>
> >>      class Size a where
> >>        size :: a -> Int
> >>      #ifdef HAS_DEFAULT_SIGNATURE
> >>        default size :: Generic a => a -> Int
> >>      size x = ...Generics based implementation...
> >>      #endif
> >>
> >> Now, if the client code doesn't exploit the default-signature
> >> implementation, then the client code is perfectly portable, and even if
> >> the conditional API features are available they have no visible effect
> >> whatsoever.
> >>
> >> OTOH, if the client code wants to make use of the default
> >> implementation, it needs to be built with a compiler supporting the
> >> Generics language feature, and due to a) the library is guaranteed to
> >> provide the default-signature implementation as well as soon as the
> >> client is able to use it. The client-code is now deliberately
> >> non-portable (but on the other hand, the operational semantics are
> >> guaranteed to be consistent, as there's only one case to consider)
> >
> > That is, if I want to write a package that is portable I have to
> > implement 'size' myself. But if I forget to do so then GHC will not
> > warn me. That is, I have to know and remember that 'size' is somehow
> > special.
>
>  a) If you are allowed to forget to implement 'size', then your type was
>     able to provide a 'Generic' instance, how was that instance possible
>     to come into existence in the first place?
>
>  b) what if GHC provided something akin to a
>     -fwarn-instantiate-default-signatures GHC option, which might even
>     be turned on by default?
>
>  c) what if GHC behaved like outlined in
>     http://hackage.haskell.org/trac/ghc/ticket/7395#comment:7 instead?
>
> > APIs that change according to available compiler features are more
> > problematic than they look first. E.g. QuickCheck depends on
> > TemplateHaskell if you run on GHC. That is, if you run on GHC then a
> > module is included that provides TemplateHaskell functions. If you do
> > not run on GHC this module is not included because you cannot use it
> > anyway. However, this way QuickCheck becomes restricted to certain
> > _versions_ of GHC, because TemplateHaskell changes from version to
> > version of GHC. Thus when speaking about portability, we should always
> > think about portability between GHC versions. (My proposal for a quote
> > of the week is: GHC's strongest competitor is the next version of
> > GHC.) Will the Generics based default implementation of 'size' be
> > portable to future version of Generics?
>
> Fair enough, but breakage with newer GHCs can also happen when staying
> in the pure Haskell98/2010 domain (just think of the Num/Show/Eq
> superclass decoupling that occured in recent GHC versions). That is, for
> Haskell libraries there's always the risk needing maintainance when a
> new GHC version comes out. (But I'm not arguing this to be a good thing
> either...)
>
> > For a central package like deepseq I would prefer to provide functions
> > like genericSize that other libraries can use if they want to rely on
> > Generics. They would then write
> >
> >   instance Size Foo where
> >      size = genericSize
> >
> > instead of
> >
> >   instance Size Foo where
> >
> >
> > This would be ok, wouldn't it?
>
> Are you preferring 'genericSize' to avoid the implicity that comes with
> DefaultSignatures, and the resulting risk of inadvertently writing
> non-portable code because GHC currently doesn't warn you?
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121112/fd4e386b/attachment.htm>


More information about the Libraries mailing list