Johan Tibell writes:

On Sun, Nov 11, 2012 at 11:22 AM, Bas van Dijk wrote:

...

On 11 November 2012 15:34, Herbert Valerio Riedel wrote:

...

I'd argue that there is no harm in allowing this kind of compile-time conditional APIs using the DefaultSignature language extension.

I agree.

There's one minor issue: Say some client does not intend to rely on DefaultSignatures but forgets to write a definition for the method. He will then not get a "No explicit method or default declaration" warning. However, in this case I think the benefits outweigh this disadvantage.

FWIW I prefer that deepseq and hashable both use the DefaultSignatures extension to provide generic default definitions.

hashable won't be using DefaultSignatures. See the discussion here:

https://github.com/tibbe/hashable/pull/33

Update: However, starting with hashable-1.2.0.0 DefaultSignatures are being used notwithstanding :-) cheers, hvr

Bas van Dijk writes: [...]

There's one minor issue: Say some client does not intend to rely on DefaultSignatures but forgets to write a definition for the method. He will then not get a "No explicit method or default declaration" warning. However, in this case I think the benefits outweigh this disadvantage.

...maybe the following shameless plug offers a different perspective in the design-space of DefaultSignatures: http://hackage.haskell.org/trac/ghc/ticket/7395#comment:7 But I'm not sure yet, whether handling DefaultSignatures implementations more like builtin classes and keeping vanilla H98 typeclass default-implementations in separate "namespace" would actually help here...

Henning Thielemann 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?

* José Pedro Magalhães [2012-11-12 09:27:17+0000]

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.

Do you propose exposing genericSize conditionally? I'm strongly against this. I think that packages' interfaces may not depend on the compiler or compilation options. Only the implementation of the intreface may.

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.

Can't we simply ignore default signatures (and corresponding default definitions) when DefaultSignatures is off? E.g. instance Show Foo is accepted in any case, but has different semantics depending on whether DefaultSignatures is on. This way it's more Haskell2010 compatible. I realise that changing semantics is not very good, but people usually test this kind of code anyway, so I don't think it will be a big problem in practice. In that case it'd make sense to add a separate flag (-XUseGenericDefinition?) whose impact on the program semantics is more obvious from its name. Roman

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 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 wrote:

...

Henning Thielemann 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries