Also: Platform includes QuickCheck which has a conditional API for
TemplateHaskell support. I wouldn't be surprised if there are more examples
like that.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskel
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
On Tue, Nov 6, 2012 at 3:32 PM, Herbert Valerio Riedel wrote:
> Clark Gaebel writes:
> | There's no disadvantage to having the generic functionality in a
> | separate package, right?
>
Well for one it means you can't simply write
instance Class Type
but must write
instance Class Ty
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 someon
Clark Gaebel 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 to quote a succinct
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, anywa
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, 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" wrote:
> Clark Gaebel writes:
>
> > @dag:
> >
> > I w
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
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.H
On Sun, Nov 4, 2012 at 5:39 PM, Johan Tibell 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 parseRecord :: (G
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 implementa
@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 ta
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 wrote:
> Clark Gaebel writes:
>
> [...]
>
> > Oh yeah, and if anyone wants t
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
http://www.haskell.org/mailman/listinfo
Clark Gaebel 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 your 'HandRolled'; but
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 DeriveG
17 matches
Mail list logo
