Re: RFC: Can DefaultSignature compile-time conditional APIs be regarded "benign"?
Bas van Dijk <v.dijk.bas <at> gmail.com>
2012-11-12 09:45:43 GMT
I like those ideas.
However this still leaves #7395 unresolved.
I do like hvr's idea of using the deriving mechanism to derive classes
On 12 November 2012 10:27, José Pedro Magalhães <jpm <at> cs.uu.nl> wrote:
> 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
> 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
>> > 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
> Libraries mailing list
> Libraries <at> haskell.org
Libraries mailing list
Libraries <at> haskell.org