I like those ideas.
However this still leaves #7395 unresolved.
I do like hvr's idea of using the deriving mechanism to derive classes
with DefaultSignatures.
Bas
#7395 http://hackage.haskell.org/trac/ghc/ticket/7395
On 12 November 2012 10:27, José Pedro Magalhães <jpm at cs.uu.nl> wrote:
> 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>>>> _______________________________________________
> Libraries mailing list
>Libraries at haskell.org>http://www.haskell.org/mailman/listinfo/libraries>