April 2012 - Haskell-Cafe

Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
by Jason Dagit 20 Jun '12

20 Jun '12

In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C. Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds <magicloud.magiclouds(a)gmail.com> wrote: > Well, cabal-dev could not resolve the conflict of "the diamond". > Because the conflict is "depending different version at the SAME > time". > > On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit <dagitj(a)gmail.com> wrote: >> On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds >> <magicloud.magiclouds(a)gmail.com> wrote: >>> Hello, >>> As I recalled, ghc works in staticly link mode. So after one library >>> is compiled, all its build dependencies are useless. Lost, changed, >>> wheresoever, it does not matter. >>> Then why the problem of version conflicting exists? >> >> I'm not sure, but for me this problem has gone away by using cabal-dev >> to build everything. >> >> Jason > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com.

4 9

Fundeps and overlapping instances
by Simon Peyton-Jones 09 Jun '12

09 Jun '12

Oleg points out, and Martin also mentions, that functional dependencies appear to interact OK with overlapping instances, but type families do not. I this impression is mistaken, and I'll try to explain why in this message, in the hope of exposing any flaws in my reasoning. We can't permit overlap for type families because it is unsound to do so (ie you can break "well typed programs don't go wrong"). But if it's unsound for type families, it would not be surprising if it was unsound for fundeps too. (I don't think anyone has done a soundness proof for fundeps + local constraints + overlapping instances, have they?) And indeed I think it is. So the short summary of this message is: if it works for fundeps it works for type families, and vice versa. (NB this equivalence is not true about GHC's current implementation, however. GHC doesn't support the combination of fundeps and local constraints at all.) Such an equivalence doesn't argue against fundeps; I'm only suggesting the that the two really are very closely equivalent. I much prefer type families from a programming-style point of view, but that's a subjective opinion. Simon Imagine a system "FDL" that has functional dependencies and local type constraints. The big deal about this is that you get to exploit type equalities in *given* constraints. Consider Oleg's example, cut down a bit: class C a b | a -> b instance C Int Bool newtype N2 a = N2 (forall b. C a b => b) t2 :: N2 Int t2 = N2 True We end up type-checking (True :: forall b. C Int b => b). From the functional dependency we know that (b~Bool), so the function should typecheck. GHC rejects this program; FDL would not. But making use of these extra equalities in "given" constraints is quite tricky. To see why look first at Example 1: module X where class C a b | a -> b data T a where MkT :: C a b => b -> T a module M1 where import X instance C Int Char where ... f :: Char -> T Int f c = MkT c module M2 where import X instance C Int Bool g :: T Int -> Bool g (MkT x) = x module Bad where import M1 import M2 bad :: Char -> Bool bad = g . f This program is unsound: it lets you cast an Int to a Bool; result is a seg-fault. You may say that the problem is the inconsistent functional dependencies in M1 and M2. But GHC won't spot that. For type families, to avoid this we "eagerly" check for conflicts in type-family instances. In this case the conflict would be reported when compiling module Bad, because that is the first time when both instances are visible together. So any FDL system should also make this eager check for conflicts. What about overlap? Here's Example 2: {-# LANGUAGE IncoherentInstances #-} module Bad where import X -- Overlapping instances instance C Int Bool -- Instance 1 instance C a [a] -- Instance 2 f :: Char -> T Int f c = MkT c -- Uses Instance 1 g :: T a -> a g (MkT x) = x -- Uses Instance 2 bad :: Char -> Int bad = g . f Again, a seg fault if it typechecks. But will it? When typechecking 'g', we get a constraint (C a ?), where 'a' is a skolem constant. Without IncoherentInstances GHC would reject the program on the grounds that it does not know what instance to choose. But *with* IncoherentInstances it would probably go through, which is unsound. So IncoherentInstances has moved from causing varying dynamic behaviour to causing seg faults. Very well, so FDL must get rid of IncoherentInstances altogether, at least for classes that have functional dependencies (or that have superclasses that do). But at the moment GHC makes an exception for *existentials*. Consider Example 3: class C a b | a -> b -- Overlapping instances instance C Int Bool -- Instance 1 instance C a [a] -- Instance 2 data T where MkT :: C a b => a -> b -> T f :: Bool -> T f x = MkT (3::Int) x -- Uses Instance 1 g :: T -> T g (MkT n x) = MkT n (reverse x) -- Uses Instance 2 bad :: Bool -> T bad = g . f In the pattern match for MkT in g we have the constraint (C a b), where 'a' is existentially bound. So under GHC's current rules it'll choose the (C a [a]) instance, and conclude that (b ~ [a]). So it's ok to reverse x. But it isn't; see function bad! So to avoid unsoundness we must not choose a particular instance from an overlapping set unless we know, absolutely positively, that the other cases cannot match. (GHC's exception for existentials was introduced in response to user demand. Usually, overlapping instances are somehow semantically coherent, and with an existential we are *never* going to learn more about the instantiating type, so choosing the best available seems like a good thing to do.) But even nuking IncoherentInstances altogether is not enough. Consider this variant of Example 3, call it Example 4: module M where class C a b | a -> b instance C a [a] -- Instance 2 data T where MkT :: C a b => a -> b -> T g :: T -> T g (MkT n x) = MkT n (reverse x) -- Uses Instance 2 module Bad where import M instance C Int Bool -- Instance 1 f :: Bool -> T f x = MkT (3::Int) x -- Uses Instance 1 bad :: Bool -> T bad = g . f This is nasty. In module M we have only one instance declaration for C, so there's no overlap, and function g typechecks fine. Now module Bad adds an overlapping instance declaration and 'f' uses it; moreover, it's clear that the new instance declaration is the right one to use. It's not clear how to fix this. The only way I can think of is to insist that all the instances appear in a single module, so that you cannot add more "later". But that loses part of the point of overlap in the first place, namely to provide a generic instance and then later override it. So FDL must * embody eager checking for inconsistent instances, across modules * never resolve overlap until only a unique instance can possibly match * put all overlapping instances in a single module Type families already implement the first of these. I believe that if we added the second and third, then overlap of type families would be fine. (I may live to eat my words here.) I'd be interested to know what Chameleon does on these examples.

6 18

GHC 7.4 and TypeSynonymInstances
by Ivan Lazar Miljenovic 07 Jun '12

07 Jun '12

Has there been a change in the behaviour/requirement of TypeSynonymInstances as of GHC-7.4.1? (Not sure if this behaviour occurs with 7.2.1 as I don't have it installed) I had an instance for String for a class which ghc accepted whilst using FlexibleInstances; however, when trying to load it in 7.0.* it stated that TypeSynonymInstances was needed (which I forgot to add since it didn't seem to need it). All I could find in the release notes was that as of 7.2.1, both extensions were needed, not that one implied the other: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-2-1.html#i… Is this behaviour deliberate, or a bug? -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

3 4

Install a script with Cabal?
by Ketil Malde 05 Jun '12

05 Jun '12

Hi, I have a small project that installs a couple of Haskell tools and a script that uses these. Cabal will of course build and install the Haskell programs, but how can I get Cabal to install the script as well? There's a host of UserHooks available¹, but it'd probably be better to have an example than to try to experiment with the right configuration. -k ¹ http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distributio… -- If I haven't seen further, it is by standing in the footprints of giants

3 4

Correspondence between libraries and modules
by Alvaro Gutierrez 25 May '12

25 May '12

Hi there, I've only dabbled in Haskell, so please excuse my ignorance: why isn't there a 1-to-1 mapping between libraries and modules? As I understand it, a library can provide any number of unrelated modules, and conversely, a single module could be provided by more than one library. I can see how this affords library authors more flexibility, but at a cost: there is no longer a single, unified view of the library universe. (The alternative would be for every module to be its own, hermetic library.) So I'm very interested in the rationale behind that aspect of the library system. Thanks! Alvaro

8 20

Linear Diaphantine equation solver bug
by John D. Ramsdell 12 May '12

12 May '12

I uploaded a new version of the ACU unifier in package cmu. It includes a Linear Diaphantine equation solver that now handles inhomogeneous equations. What's interesting is the algorithm is based on a paper by Contejean and Devie. That paper includes a proof of correctness of their algorithm. Yet I found an example in which following the steps in the order they gave, the algorithm produces extra answers. I had to switch the order of the steps in the algorithm to get the right answer. I wonder if anyone else knows of this issue. The example is given in the module documentation on Hackage. John http://hackage.haskell.org/packages/archive/cmu/1.6/doc/html/Algebra-Commut…

1 1

Template Haskell: Generate annotated function of a typeclass
by Ismael Figueroa Palet 10 May '12

10 May '12

Hi all, I think this is the right place for the following questions and I thank beforehand for your answers :-) I'm experimenting with typeclasses and TH, and I want to define a 'macro' that works more or less like this: Given the name of a typeclass and a function, return the expressions corresponding to the type-annotated instances, for instance $(foo Show show) should translate to: ["(show :: Int -> String)", "(show :: Bool -> String)", ....] for all instances currently in scope. I'm currently playing with the isInstance function (I'm running GHC 7.4.1) and can get a list of instances, and check if a given type is part of a typeclass or not. But I don't know how to create the expression corresponding to "instantiated function", as above. Thanks! -- Ismael

2 3

Generalizing (++) for monoids instead of using (<>)
by aditya bhargava 04 May '12

04 May '12

After asking this question: http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data… I found out that the new infix operator for `mappend` is (<>). I'm wondering why ghc 7.4 didn't generalize (++) to work on monoids instead. To me, (++) is much more clear. (<>) means "not equal to" for me. Can anyone shed light on this decision? Adit -- adit.io

9 9

Threads and hGetLine
by H. M. 02 May '12

02 May '12

Hello, The simplified problem: There are two threads, one which is waits on input via hGetLine and another, which should terminate this thread or close this handle. hClose as well as killThread doesn't seem to work, caused by the fact, that the thread is blocked until input is availiable. Hopefully you have some solution how to kill the thread and/or close the handle and/or have some other idea to get the lined input in the other thread. -- Thanks in advance H.

4 3

Haskell Hackathon in Munich
by Heinrich Hördegen 02 May '12

02 May '12

Dear all, the Munich Haskell Meeting is glad to announce a local one day Hackathon in Munich. It will take place the 12th of May 2012 from 10am to 6pm. Please checkout the details at: http://www.haskell-munich.de/dates Cordially yours, Heinrich -- -- hoerdegen(a)funktional.info www.funktional.info --

2 1