Dear Edward,
Am Samstag, den 10.05.2014, 08:04 +1000 schrieb Edward Kmett:
that is good to know. But please understand that we (the Debian
> template-haskell has to be used there because otherwise those
> instances are orphans in another package, which is not an acceptable
> packaging option to me as it breaks a ton of users. That said, if you
> don't have template-haskell on those platforms, those instances could
> never be used, but the rest of reflection is still usable.
maintainers) are not in a position to scrutinize all library packages
that deeply and assess the effect of patching out TH-related features.
It would be more realistically if the necessary Cabal flag and CPP
switches are maintained by the authors, i.e. you. This would give us
some confidence that having your package on non-TH architectures is
useful.
> They are not needed to support the core usecase of reflection. TheyThe question will then be: How much of the remaining 10% uses is in
> are needed however, to allow the user to use template-haskell splices
> to get constant natural numbers that are instances of Reifies. This is
> a 'niche'-like usecase, however, and doesn't affect 90% of the users
> of the library.
reverse dependencies in Debian, and again require manual intervention.
> If the decision for packaging in debian is that you want to not bringNo, the template-haskell package itself is fine (I believe); it is uses
> in the template-haskell package, then these could be excised from the
> debian version of the package with little damage to most users,
> especially as long as you are packaging a GHC >= 7.6.3.
of TemplateHaskell that need to be patched out. And that includes for
example the call to makeAllTupleIxed in Control.Lens.At – how integral
is that feature to lens?