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.
___
Haskell-Cafe mailing list
Clark Gaebel cgae...@uwaterloo.ca 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
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,
Clark Gaebel cgae...@uwaterloo.ca writes:
For the merge into Hashable, the default instance is only included if we're
on a compatible GHC.
I originally tried to make the same argument for enhancing `deepseq`,
but I was made aware this would lead to a conditional API, which is
frowned upon, or
Clark Gaebel cgae...@uwaterloo.ca writes:
[...]
Oh yeah, and if anyone wants to help me figure out why it's 1.3x slower
than my hand-rolled instances, that would be really helpful.
[...]
I've taken a look at the bench/Bench.hs benchmark[1]:
The generated Core looks almost[2] the same as
Have you talked with upstream about possibly adding this to hashable
proper, using DefaultSignatures? CPP can be used to make it portable to
older GHC versions.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Thanks a lot!
I've updated the benchmark accordingly, and have released a new version
without the 1.3x slowdown disclaimer as generic-hashable 1.1.8.
- Clark
On Sun, Nov 4, 2012 at 10:25 AM, Herbert Valerio Riedel h...@gnu.org wrote:
Clark Gaebel cgae...@uwaterloo.ca writes:
[...]
Oh
@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.
- Clark
On Sun, Nov 4, 2012 at 10:30 AM, dag.odenh...@gmail.com
dag.odenh...@gmail.com wrote:
Have you
On Sun, Nov 4, 2012 at 8:35 AM, Clark Gaebel cgae...@uwaterloo.ca 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
On Sun, Nov 4, 2012 at 5:39 PM, Johan Tibell johan.tib...@gmail.com wrote:
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
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 johan.tib...@gmail.comwrote:
On Sun, Nov 4, 2012 at 8:35 AM, Clark Gaebel cgae...@uwaterloo.ca wrote:
@dag:
I would love
Clark Gaebel cgae...@uwaterloo.ca 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
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 h...@gnu.org wrote:
Clark Gaebel cgae...@uwaterloo.ca
Hi everybody!
I have just released a handy package on Hackage that will interest you if
you've ever used unordered-containers with a custom type.
In order to do such a thing, you'd need to define an instance of Hashable.
This process could easily be automated.
And so I did.
{-# LANGUAGE
14 matches
Mail list logo
