Am Donnerstag 19 November 2009 01:07:37 schrieb Henning Thielemann:

Kapil Hari Paranjape schrieb:

...

Hello,

On Sat, 14 Nov 2009, Jaco van Iterson wrote:

...

Only installation with 'cabal install yi' in a Cygwin shell under MS Windows XP ended in: Yi\Prelude.hs:182:9: Duplicate instance declarations: instance Category Accessor.T -- Defined at Yi\Prelude.hs:182:9-38 instance Category Accessor.T -- Defined in data-accessor-0.2.1:Data.Accessor.Private cabal.exe: Error: some packages failed to install: yi-0.6.1 failed during the building phase. The exception was: exit: ExitFailure 1

Seems easy to fix but I can't even find where on my drive I can find the source code.

Where is the source?

Seems to be that the author defined an orphan instance - something one should never do!

So what do you do if you need an instance ClassX TypeY but the author of the package that defines TypeY hasn't provided one? You can define an orphan instance or duplicate packageY but with the instance. Both are bad. Providing an orphan instance until packageY has one seems the lesser evil to me. Are there any good options?

Am Donnerstag 19 November 2009 03:03:09 schrieb Henning Thielemann:

Daniel Fischer schrieb:

...

Am Donnerstag 19 November 2009 01:07:37 schrieb Henning Thielemann:

...

Seems to be that the author defined an orphan instance - something one should never do!

So what do you do if you need an instance ClassX TypeY but the author of the package that defines TypeY hasn't provided one?

The author (me) has added the instance after it became aware to him (me) ...

Of course :)

...

You can define an orphan instance or duplicate packageY but with the instance. Both are bad. Providing an orphan instance until packageY has one seems the lesser evil to me. Are there any good options?

A separate package for that orphan instance would be the best solution.

I'm not sure that's really better. With a separate package, you'd have dependencies packageY, orphanInstance. When a new version of packageY with the instance is uploaded, things break in the same way. The fix is easy either way, delete the dependency orphanInstance or delete the orphan instance, but with a separate package, that stays around polluting hackage - or is there now a way to remove packages from hackage swiftly? Perhaps the very best method is to contact the author/maintainer of packageY and say you need the instance.

Hi, Am Donnerstag, den 19.11.2009, 03:29 +0100 schrieb Daniel Fischer:

Perhaps the very best method is to contact the author/maintainer of packageY and say you need the instance.

but this might not be desirable when the data type and the class definition are in separate packages, and the author of the package with the data type is not willing to add additional dependencies to his package (which is a valid goal). Or how would you proceed if you need a Binary instance (from package binary) for UTCTime (from package date), as I do in arbtt? Greetings and thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

Dear Ashley Yakeley, Am Donnerstag, den 26.11.2009, 20:32 +0100 schrieb Daniel Fischer:

Am Donnerstag 26 November 2009 19:44:11 schrieb Joachim Breitner:

...

Or how would you proceed if you need a Binary instance (from package binary) for UTCTime (from package date), as I do in arbtt?

I need instance Binary UTCTime for my project, and instances for the other data types would be handy as well. If you consider such an instance of general use, it would be nice if you'd upload a new version of your package with that instance to hackage soon. Otherwise, I'll use an instance in my own package. Please let me know your decision, Regards, Joachim PS@-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 packages that provide data types (like time) depend on all the libraries that do some kind of conversion (binary, html, xhtml, json, yaml, etc.)? -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

On Thu, Nov 26, 2009 at 3:47 PM, Antoine Latter 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.

The only way to do this in a reasonable way is with multiple packages and orphan instances:

mypackage mypackage-classes-tf mypackage-classes-fd

where the 'classes' packages do nothing but provide class implementations.

This is the method I'm using for my own monad transformer library. I initially considered using a flag to specify which instances to provide, but I concluded that providing a consistent API was more important than avoiding orphan instances. 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 to handle this more transparently, perhaps by allowing packages to depend on flagged versions of other packages (e.g., foomonad >= 4.0 && < 4.1 && HAS_MTL) or some sort of bundled "intersection" packages.

But then we're in a tight spot if someone doesn't notice that I have the mypackage-classes-tf package released, provides their own instances, and ships them in a library.

Am I missing something? And how can we extend the language to make this better? Does anything short of class-instance explicit import/export make this better?

With FlexibleContexts, GHC will accept code that depends on not-yet-known instances. {-# LANGUAGE FlexibleContexts #-} module Foo where foo :: (Monad (Either Char)) => Int -> Either Char Bool foo i = do if i < 0 then Left 'a' else Right () return False If I write another module that imports Foo and has an instance for Monad (Either Char) in scope, I can call foo. Otherwise, I get a type error. -- Dave Menendez http://www.eyrie.org/~zednenem/

On Sun, Nov 29, 2009 at 5:37 AM, Duncan Coutts 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 additional packages for orphans.

The best long-term solution is probably extending Cabal to handle this more transparently, perhaps by allowing packages to depend on flagged versions of other packages (e.g., foomonad >= 4.0 && < 4.1 && HAS_MTL)

Not going to happen. Such packages could not be translated into binary distro packages.

Duncan

Wouldn't the distro just choose one set of flags for each package and then other packages would either be satisfied or not satisfied based on which flags had been chosen? It seems to me that distros could even offer multiple options for the same package with different flags set. What wouldn't work? Alex

On Sun, Nov 29, 2009 at 4:41 PM, Duncan Coutts wrote:

On Sun, 2009-11-29 at 09:55 -0800, Alexander Dunlap wrote:

...

On Sun, Nov 29, 2009 at 5:37 AM, Duncan Coutts 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 additional packages for orphans.

The best long-term solution is probably extending Cabal to handle this more transparently, perhaps by allowing packages to depend on flagged versions of other packages (e.g., foomonad >= 4.0 && < 4.1 && HAS_MTL)

Not going to happen. Such packages could not be translated into binary distro packages.

Duncan

Wouldn't the distro just choose one set of flags for each package and then other packages would either be satisfied or not satisfied based on which flags had been chosen?

Here's the system I assumed you were talking about. You can tell me if I misunderstood.

Instead of having N * M packages, you have a package that provides "optional" instances. For example package A defines a class and optionally provides instances for types defined in B. If you select to have it depend on B then the instances are provided, otherwise not.

In a source based system this seems to work ok, you would provide optional instances for all the packages you already happen to have installed. Though if later you install another package that could have had optional instances provided then you have to go recompiling things.

It's slightly worse for binary packages because the distro has to decide up front if they're going to provide the optional instances or not. Since someone might need them then you end up picking the maximal set of optional dependencies and you end up pulling in all sorts of apparently unrelated packages.

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 translated into packages in most distros. Yes you could pick the flags up front, but you have to pick a single assignment that satisfies everyone.

Well, that happens anyway with most packages since distros have to choose one set of flags that works. The proposal I was commenting on would just allow packages to depend on flags of other packages and so be explicit about this.

...

It seems to me that distros could even offer multiple options for the same package with different flags set.

Most distros cannot handle installing multiple instances of the same version of a package.

Well, what I've seen is having different packages, i.e. foo-quickcheck, foo-no-quickcheck as separate packages. (Note that I can't take credit for suggesting the idea, I was just asking you about your objection.) Thanks! Alex

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 translated into packages in most distros. Yes you could pick the flags up front, but you have to pick a single assignment that satisfies everyone.

Well, that happens anyway with most packages since distros have to choose one set of flags that works. The proposal I was commenting on would just allow packages to depend on flags of other packages and so be explicit about this.

Ah but flags are not allowed to change the public exported API of a library. That's why we do not need to depend on packages with flags set. This is an important property because it means you do not need multiple instances of a package version, any set of flags will do. Note that one distro that does have this feature of being able to depend on packages built with a particular flag is Gentoo. I don't know of any binary distros that do this.

...

...

It seems to me that distros could even offer multiple options for the same package with different flags set.

Most distros cannot handle installing multiple instances of the same version of a package.

Well, what I've seen is having different packages, i.e. foo-quickcheck, foo-no-quickcheck as separate packages.

I think you'll find that distros do not like it, especially once there is more than one flag, since the number of combinations goes up exponentially. Duncan

On Mon, 2009-11-30 at 13:36 +0100, Bas van Dijk wrote:

On Mon, Nov 30, 2009 at 11:35 AM, Duncan Coutts 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 is actually. It should probably be mentioned in the user guide section on conditionals. You can tell it's wrong because there is no way for dependent packages to specify that they need your package to export, say the Text instance.

The reason I ask is because I have a small package on hackage that violates this:

http://hackage.haskell.org/package/to-string-instances

It will fail if you install packages in the "wrong" order. To users this will seem essentially random. Duncan

On Sun, 2009-11-29 at 16:42 -0500, David Menendez wrote:

On Sun, Nov 29, 2009 at 8:37 AM, Duncan Coutts 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 additional packages for orphans.

The best long-term solution is probably extending Cabal to handle this more transparently, perhaps by allowing packages to depend on flagged versions of other packages (e.g., foomonad >= 4.0 && < 4.1 && HAS_MTL)

Not going to happen. Such packages could not be translated into binary distro packages.

Do you mean that specific idea won't happen, or that no attempt will be made to reduce the orphan problem?

I mean specifically proposal to change the Cabal package semantics such that they cannot be translated into native system binary packages on various platforms. It's vital to distributing our work that we can produce sensible binary packages on the platforms that people want to use. I should also note that distros will not look kindly on solutions that require N * M separate packages. Duncan

On Wed, Dec 02, 2009 at 11:03:52PM +0100, Joachim Breitner wrote:

Hi,

Am Montag, den 30.11.2009, 00:30 +0000 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 to the instance-Providing-problem. And which is why I’m trying to revive the thread now :-)

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?

It is technically possible, using Template Haskell, by exporting a TH value representing the instance, which can be constructed without importing the module where the class is defined, and leaving it to the importer (which has that module imported as well) to splice in the class declaration. ----- file A.hs module A where class Foo a where foo :: Int -> a ----- file B.hs {-# LANGUAGE TemplateHaskell #-} module B where import Language.Haskell.TH -- do not import A newtype Bar = Bar Int deriving Show -- the TH equivalent of "instance Foo Bar where foo = Bar" instanceFooBar :: Q [Dec] instanceFooBar = return [InstanceD [] (AppT (ConT $ mkName "A.Foo") (ConT $ mkName "B.Bar")) [ValD (VarP $ mkName "foo") (NormalB (ConE $ mkName "B.Bar")) []]] ----- file C.hs {-# LANGUAGE TemplateHaskell #-} import A import B $(instanceFooBar) main = print (foo 3 :: Bar) ----- Needless to say it would be preferable not to write instances directly as TH syntax trees! Unfortunately (for our purposes) the definition "instanceFooBar = [d| instance A.Foo Bar where foo = Bar |]" is rejected by the compiler unless A is imported in B (it complains that A.Foo and foo are not in scope). I suppose one could create a class B.Foo with the same definition as A.Foo, write a quoted instance referring to A.Foo, and use some generic programming to replace all occurrences of B.Foo with A.Foo. Of course, module B still sort of depends on module A in the sense that if the definition of A.Foo changes, importers of B will no longer be able to use instanceFooBar until B is updated. On the other hand B could export TH descriptions of multiple instance corresponding to different versions of A.Foo, relying on the importer to select the one which matches its selected version of A. Regards, Reid Barton

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 would entail that one would only ask for instances of the more prominent classes (Show, Read, Eq, Ord, Numerical classes, Monad, Functor, Applicative*; Binary would qualify too, I believe).

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 packages that provide data types (like time) depend on all the libraries that do some kind of conversion (binary, html, xhtml, json, yaml, etc.)?

No, that'd be too much indeed. * that list is not meant to be exhaustive, just what sprang to mind.