On Wed, 2009-12-02 at 23:03 +0100, Joachim Breitner wrote:
Would it be techically possible and feasible to write instance that do
not actually cause a dependency on the package that defines the class
resp. the data type? From a distributor point of view, I could live
quite well with a setup
Hi,
Am Montag, den 30.11.2009, 00:30 + schrieb Duncan Coutts:
I should also note that distros will not look kindly on solutions that
require N * M separate packages.
with my Debian-Developer hat on I can very much support this statement.
Which is why I’m so interested in a proper solution
On Wed, Dec 02, 2009 at 11:03:52PM +0100, Joachim Breitner wrote:
Hi,
Am Montag, den 30.11.2009, 00:30 + schrieb Duncan Coutts:
I should also note that distros will not look kindly on solutions that
require N * M separate packages.
with my Debian-Developer hat on I can very much
On Sun, 2009-11-29 at 19:38 -0800, Alexander Dunlap wrote:
Then the other bit you suggested foomonad = 4.0 4.1 HAS_MTL
would be needed to be able to express that you want a package that has
been built with a particular optional instance provided. This is the bit
that cannot be
On Mon, Nov 30, 2009 at 11:35 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
Ah but flags are not allowed to change the public exported API of a
library.
I wasn't aware of this. Where is this documented?
The reason I ask is because I have a small package on hackage that
violates this:
On Mon, 2009-11-30 at 13:36 +0100, Bas van Dijk wrote:
On Mon, Nov 30, 2009 at 11:35 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
Ah but flags are not allowed to change the public exported API of a
library.
I wasn't aware of this. Where is this documented?
Hmm, I'm not sure it
On Thu, 2009-11-26 at 16:40 -0500, David Menendez wrote:
The problem with this solution is that it doesn't scale. If we have M
packages providing types and N packages providing classes, then we
need M*N additional packages for orphans.
The best long-term solution is probably extending Cabal
On Sun, Nov 29, 2009 at 5:37 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Thu, 2009-11-26 at 16:40 -0500, David Menendez wrote:
The problem with this solution is that it doesn't scale. If we have M
packages providing types and N packages providing classes, then we
need M*N
On Sun, Nov 29, 2009 at 8:37 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Thu, 2009-11-26 at 16:40 -0500, David Menendez wrote:
The problem with this solution is that it doesn't scale. If we have M
packages providing types and N packages providing classes, then we
need M*N
On Sun, 2009-11-29 at 16:42 -0500, David Menendez wrote:
On Sun, Nov 29, 2009 at 8:37 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Thu, 2009-11-26 at 16:40 -0500, David Menendez wrote:
The problem with this solution is that it doesn't scale. If we have M
packages providing
On Sun, 2009-11-29 at 09:55 -0800, Alexander Dunlap wrote:
On Sun, Nov 29, 2009 at 5:37 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Thu, 2009-11-26 at 16:40 -0500, David Menendez wrote:
The problem with this solution is that it doesn't scale. If we have M
packages providing
On Sun, Nov 29, 2009 at 4:41 PM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Sun, 2009-11-29 at 09:55 -0800, Alexander Dunlap wrote:
On Sun, Nov 29, 2009 at 5:37 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Thu, 2009-11-26 at 16:40 -0500, David Menendez wrote:
The
On Thu, Nov 26, 2009 at 2:27 PM, Joachim Breitner
m...@joachim-breitner.de wrote:
p...@-cafe:
I still have doubts that this approach will scale as hackage grows. We’d
get a lot more dependencies than we have now, and still would face this
problem every now and then. Or do you really want
Am Donnerstag 26 November 2009 21:27:53 schrieb Joachim Breitner:
I still have doubts that this approach will scale as hackage grows.
True. I gratuitously assumed that one would ask only if one believes such an
instance
would be *generally* useful, not only for the one project at hand. That
On Thu, Nov 26, 2009 at 3:47 PM, Antoine Latter aslat...@gmail.com wrote:
Lets say I want to provide an alternate or additional library of monad
transformer data types. To make these types maximally useful, they
should implement the typeclasses in the mtl package and in the
monads-tf package.
Hello All
For instances on UTCTime - isn't UTCTime more 'canoncial' than
data-binary etc. by virtue of it being in the Hierarchical Libraries?
Thus data-binary should provide an instance of Binary for UTCTime -
rather than Time provide a Binary instance.
Also, aside from cases where automatic
16 matches
Mail list logo
