On Sun, Nov 4, 2012 at 8:35 AM, Clark Gaebel wrote:

@dag:

I would love for this to be merged into Data.Hashable, and I think it would make a lot of people's lives easier, and prevent them from writing bad hash functions accidentally.

Couldn't we do it using GHC's default implementations based on signatures features, so we don't have to expose any new things in the API? We used that in unordered-containers like so: #ifdef GENERICS default parseRecord :: (Generic a, GFromRecord (Rep a)) => Record -> Parser a parseRecord r = to <$> gparseRecord r #endif -- Johan

Yes. Sorry if I wasn't clear. That's what I intended. So would a patch adding this to hashable be accepted? - Clark On Sun, Nov 4, 2012 at 11:39 AM, Johan Tibell wrote:

On Sun, Nov 4, 2012 at 8:35 AM, Clark Gaebel wrote:

...

@dag:

I would love for this to be merged into Data.Hashable, and I think it

would make a lot of people's lives easier, and prevent them from writing bad hash functions accidentally.

Couldn't we do it using GHC's default implementations based on signatures features, so we don't have to expose any new things in the API?

We used that in unordered-containers like so:

#ifdef GENERICS default parseRecord :: (Generic a, GFromRecord (Rep a)) => Record -> Parser a parseRecord r = to <$> gparseRecord r #endif

-- Johan

How would the ghc-dependance affect hashable's inclusion in the haskell platform? Doesn't the haskell platform ship only a recent version of ghc (i.e. one with support for generics)? - Clark On Nov 4, 2012 6:00 PM, "Herbert Valerio Riedel" wrote:

Clark Gaebel writes:

...

@dag:

I would love for this to be merged into Data.Hashable, and I think it would make a lot of people's lives easier, and prevent them from writing bad hash functions accidentally.

Jfyi, a discussion came up when I posted a proposal to add a generics-based NFData deriver to the 'deepseq' package, with the result that the generics-based code was put in the separate `deepseq-generics` package:

http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17940

...and since there's plan (iirc) to bring the 'hashable' package into the haskell-platform, some of the arguments brought up in that thread with respect to the 'deepseq' package might apply here as well.

cheers, hvr

For the merge into Hashable, the default instance is only included if we're on a compatible GHC. This means Hashable itself will be portable, but it strongly encourages other packages not to be. I think the portability requirement is just used as an easy way to filter out lower quality code, anyway. - Clark On Tue, Nov 6, 2012 at 6:31 AM, Herbert Valerio Riedel wrote:

Clark Gaebel writes:

...

How would the ghc-dependance affect hashable's inclusion in the haskell platform? Doesn't the haskell platform ship only a recent version of ghc (i.e. one with support for generics)?

I was under the impression that the haskell platform, albeit currently bundling GHC, aims for portability, as in [1] its required that a package

| * Compile on all operating systems and compilers that the platform targets. [rationale-8.4]

and in [2] there's a (somewhat weaker) mention of portability as well:

| *Portability*. Good code is portable. In particular, try to ensure the | code runs in Hugs and GHC, and on Windows and Linux.

Maybe Hugs is a bit too outdated/unmaintained, but on the other hand maybe JHC and UHC compatibility should be aimed for instead these days for core packages?

[1]: http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Packagerequirem... [2]: http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_proposer...

Your first link says that any library in the Haskell Platform must be supported on all operating systems and compilers supported by the Haskell Platform. Right now, the platform only supports GHC, and on Windows, Linux, and Mac. This change does not break any of those. I say this because if someone tries to file a ticket for the haskell platform saying it doesn't work on Hugs (for example), that ticket will be immediately closed as WontFix. The second link you mentioned was for GHC core libraries. I'm not sure about Johan's intentions, but I wouldn't expect Hashable to become a core library. As for the difference between deepseq and Hashable - there's very little as far as I know, except for different maintainers. Johan has expressed interest in getting the changes merged, so I prepared a pull request for him. When I say "encouraging other packages not be to portable", you were absolutely right in your assumption that I meant that a package depending on Hashasble will more likely be non-portable because of the conditional API. Sorry that I wasn't clear on that. And the portability requirement didn't even seem like a hard rule. It just looked like it was trying to say that good code tends to be portable. I'm not sure if the author intended to say that *all* good code is portable. - Clark

A note: if you use generic-deriving instead of ghc-prim, the generics code could in theory be portable as well. That package re-exports from ghc-prim when compiled with GHC, and provides a compatible fallback implementation.