May 2012 - Haskell-Cafe

Hackage 2 maintainership
by Ben Gamari 26 Jun '12

26 Jun '12

Hey all, Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator. It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary. I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier). That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation. It seems that this process will go something like this, 1) Bring Hackage trac back from the dead 2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org 3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances This will surely be a non-trivial process but I would be willing to move things forward. Cheers, - Ben [1] http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html

12 17

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

Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
by Ryan Newton 18 Jun '12

18 Jun '12

Thanks David. I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I like the comment pragmas more than new keywords.) The issue that I think doesn't make it into the wiki is of splitting, not modules, but* type-classes*. That's where I think it becomes a more serious issue. Do you think a symbol-level Safe Haskell would be able to distinguish one method of a type class as unsafe, while the others are safe? -Ryan P.S. In my two examples -- There's only one "Acc" type and Accelerate's "fold" can pretty easily be moved into an .Unsafe module, though it breaks the one-giant-module-for-the-whole-programming-model thing it has going now. In the Par example on the other hand type classes are used to abstract over different implementations, so that's where we run into the safe/unsafe factoring problem.

4 7

Troubles understanding Parsec Error Handling
by Matthias Hörmann 11 Jun '12

11 Jun '12

I recently started writing my first application at work in Haskell and it deals with a lot of parsing. Among other things I often have to check for a lot of alternatives for fixed strings (parsing natural language text and people have a lot of ways to abbreviate the same thing in labels). So far I have been doing this basically via choice $ map (try . string) [ "foo", "bar", ... ] This works fine but has two disadvantages, it isn't very fast, in particular when many of the strings start with the same prefix and it also is a bit error prone since it breaks when you place a prefix of another string earlier in the list. My attempt at a solution was to use the bytestring-trie package for a little utility function that basically parses one character at a time, checks if the string parsed so far is in the trie and then calls itself recursively with the trie starting with that string. My attempt at that so far looks like this: (dependencies bytestring-trie, utf8-string and parsec 3) import qualified Data.ByteString.UTF8 as UTF8 import qualified Data.Trie as Trie import Text.Parsec import Text.Parsec.Text (GenParser) anyOf :: [String] -> GenParser u String anyOf l = try $ anyOf' t "" where t = Trie.fromList $ zip (map UTF8.fromString l) (repeat ()) anyOf' :: Trie.Trie () -> String -> GenParser u String anyOf' t s = try $ do c <- lookAhead $ anyChar let newS = s ++ [ c ] in case Trie.submap (UTF8.fromString newS) t of emptyT | Trie.null emptyT -> case Trie.member (UTF8.fromString s) t of True -> return s False -> unexpected $ show newS++", expecting one of "++show l restT -> do _ <- anyChar try $ anyOf' restT newS A successful example usage would be: parseTest (do; r1 <- anyOf ["Hello", "Hallo", "Foo", "HallofFame"]; r2 <- string "bla"; return (r1, r2)) "Hallobla" which results in ("Hallo","bla") (the extra string parser is there so errors in parsing too much are not hidden). An error would result .e.g. from parseTest (do; r1 <- anyOf ["Hello", "Hallo", "Foo", "HallofFame"]; r2 <- string "bla"; return (r1, r2)) "Hallofbla" which prints this: parse error at (line 1, column 8):unknown parse error And my question about this is made up of two parts 1. Why doesn't it print my "unexpected" message but instead says unknown parse error 2. Why is the location in the text off (I would expect it to fail at column 6 (first character beyond the result it could return) or 7 (first character that makes the string no prefix of any acceptable string) I am afraid my knowledge of Parsec internals is a bit too limited, some Google queries showed no similar problems and no obvious places in the Parsec source code to check for the answer to the first question in particular and I suspect the second is closely related to the first. Thanks for reading through my question and I hope someone knows the answer or at least some clues on where i might find it. Matthias Hoermann P.S.: I am hoping this time this works, last time it was rejected because google sends with @googlemail.com instead of @gmail.com for some reason.

4 8

vector operations
by Evan Laforge 11 Jun '12

11 Jun '12

So I wanted to find the first index in a vector whose running sum is greater than a given number. The straightforward way is to create the running sum and then search: Vector.findIndex (>=target) (Vector.scanl' (+) 0 vector) But vectors are strict so it could do extra work, and what if I don't want to generate garbage? I could do it with a fold, but it would have to have the ability to abort early. Of course I could write such a fold myself using indexing: import qualified Data.Vector.Generic as Vector fold_abort :: (Vector.Vector v a) => (accum -> a -> Maybe accum) -> accum -> v a -> accum fold_abort f accum vec = go 0 accum where go i accum = maybe accum (go (i+1)) $ f accum =<< vec Vector.!? i find_before :: (Vector.Vector v a, Num a, Ord a) => a -> v a -> Int find_before n = fst . fold_abort go (0, 0) where go (i, total) a | total + a >= n = Nothing | otherwise = Just (i+1, total+a) So it's bigger and clunkier, but I would think it would be much more efficient (provided using Data.Vector.Generic won't inhibit inlining and unboxing). But I'm a bit surprised there isn't already something like fold_abort... or is there?

4 7

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

Arithmetic expressions with GADTs: parsing
by j.romildo＠gmail.com 05 Jun '12

05 Jun '12

Hello. In order to learn GADTs, I have written the attached program, which defines a type for arithmetic expressions using GADTs, a parser for them, and an evaluation function. But my parser does not typecheck. ghc-7.4.1 gives me the error message: Expr.hs:25:28: Couldn't match expected type `Double' with actual type `Bool' Expected type: Bool -> Expr Double Actual type: Bool -> Expr Bool In the first argument of `(<$>)', namely `B' In the first argument of `(<|>)', namely `B <$> pBool' Any clues on how to fix that? Romildo

5 5

mapping a concept to a type
by Corentin Dupont 04 Jun '12

04 Jun '12

Hi everybody, I'm still working on implementing a nomic game in Haskell. Although the game is pretty advanced, I'm still confused by one fundamental question: A nomic game is composed of rules. A Rule is a sort of little program submitted by the player during the game. They come in two fashions: - a Normal rule, when executed, can change the state of the Game. - a Meta rule, when executed on another rule, can assess the legality of that rule and change the state of the Game. In those definitions, the Game can be seen as a data structure containing all the current state of the game. Sorry if it's a bit abstract, but as it's fairly complex, I'd prefer to keep it like this for the moment. Thus, I found that those definitions can be translated to two possible type definitions: type NormalRule = State Game () type MetaRule = Rule -> State Game Bool data Rule = MR MetaRule | NR NormalRule *** or *** newtype Rule = Rule {rule :: Maybe Rule -> (State Game Bool)} All rules submitted by the user must be of the type Rule. It is thus important that it is very clean. Which type do you prefer? I find both heavy and redundant. The first forces me to specify if I want an argument of not (with the constructors MR and NR), the second forces me to pass the Nothing argument in the case of a Normal rule, and to return a dummy value (for ex. return True). Do you know of a construction/abstraction that allows having or not an argument (a variable number of arguments, here zero or one)? Thanks! Corentin

3 5