Edward Kmett ekm...@gmail.com writes:
If this forced me to write those instances by hand, I could accept
that as a tax for correctness. It means you can't GND any of the
HasFoo dictionaries that lens builds, but meh.
Am I correct in assuming that Bind, R1, R2, R3, and R4 are the
problematic
# The Problem
Dynamic linking is currently broken with the LLVM code generator. This
can be easily seen by attempting to compile GHC with,
GhcDynamic = YES
DYNAMIC_BY_DEFAULT = YES
DYNAMIC_GHC_PROGRAMS = YES
BuildFlavour = quick-llvm
This build will fail with a error along the
Yes, I believe that's right. As far as I can figure out, these classes really
*are* problematic, in that if we allowed GeneralizedNewtypeDeriving for them,
there would be a way to subvert the type system. To make these derivable, we
would need to be able to restrict various type parameters from
Richard Eisenberg e...@cis.upenn.edu writes:
Yes, I believe that's right. As far as I can figure out, these classes
really *are* problematic, in that if we allowed
GeneralizedNewtypeDeriving for them, there would be a way to subvert
the type system. To make these derivable, we would need to
On Dec 14, 2013, at 7:59 PM, Ben Gamari wrote:
I suppose it's unlikely that the roles mechanism will be extended to
allow for such restriction?
Very unlikely in the short term. As more use cases for such a feature filter in
and the community demands the feature, there's no strong technical
I've spent much of the day trying to determine the root cause of,
...
inplace/bin/ghc-cabal register libraries/ghc-prim dist-install
/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc
/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc-pkg
