- Haskell-Cafe - Haskell.org

Call for Participation - ACCAT 2013
by Ulrike Golas 31 Jan '13

31 Jan '13

[We apologize if you receive multiple copies of this message.] CALL FOR PARTICIPATION ========== 8th International Workshop on Applied and Computational Category Theory ACCAT 2013 http://accat2013.zib.de/ Satellite Event of ETAPS 2013, Rome, March 17 2013 ========== Scope ===== Since the 1960s, the use of category theory in computer science has been a fruitful one, including applications to different areas such as automata theory, algebraic specification, and programming languages, among others. In recent years, techniques and methods from CT have been adopted as a standard research tool, and considered as such in different venues around the world. The ACCAT workshop on "Applied and Computational Category Theory" has been one of these venues. Since its inception in 2006, ACCAT provided a forum where invited contributors presented their own research on different facets of category theory applied to computer science. Following the tradition, the program of this year edition will include eight invited talks by top researchers in the area: Samson Abramsky Robin B. Cockett Barbara Koenig Ugo Montanari Till Mossakowski Dusko Pavlovic Andrzej Tarlecki Glynn Winskel Despite ACCAT's success, we believe that the current formula of the workshop should be deeply revised. Indeed, we believe that a fully fledged conference is missing where all kinds of applications of category theory to computer science can be presented (like the former CTCS conference, which somehow ended in 2006). Therefore, after the presentations, the workshop will end up with a general discussion among the invited speakers and the attendees. We hope that the outcome of the discussion could be a decision whether to push for such high-level workshop/conference on the application of category theory to computer science, or at least to verify the viability of a further meeting focusing on this issue. For more information, please contact Fabio Gadducci (gadducci(a)di.unipi.it) or Ulrike Golas (golas(a)zib.de) -- Dr. Ulrike Golas Konrad-Zuse-Zentrum für Informationstechnik Berlin Takustr. 7, 14195 Berlin, Germany Tel. +49 30 84185 - 318 golas(a)zib.de -- www.zib.de/golas

1 0

why GHC cannot infer type in this case?
by Dmitry Kulagin 31 Jan '13

31 Jan '13

Hi Cafe, I try to implement little typed DSL with functions, but there is a problem: compiler is unable to infer type for my "functions". It seems that context is clear, but still GHC complains "Could not deduce...". It is sad because without type inference the DSL will be very difficult to use. Could someone explain me why this happens and how it can be avoided? I use GHC 7.4.2 I tried to distill the code to show the problem (and full error message below it). Thank you! Dmitry {-# LANGUAGE GADTs, KindSignatures, DataKinds #-} module TestExp where -- Sequence of DSL's types to represent type of tuple data TSeq where TSeqEmpty :: TSeq TSeqCons :: TypeExp -> TSeq -> TSeq -- All types allowed in DSL data TypeExp where -- Primitive type TInt16 :: TypeExp -- Function type is built from types of arguments (TSeq) and type of result TFun :: TSeq -> TypeExp -> TypeExp -- Sequence of expressions to represent tuple data Seq (t :: TSeq) where SeqEmpty :: Seq TSeqEmpty SeqCons :: Exp w -> Seq v -> Seq (TSeqCons w v) data Exp (r :: TypeExp) where Decl :: (Seq args -> Exp r) -> Exp (TFun args r) Call :: Exp (TFun args r) -> Seq args -> Exp r Int16 :: Int -> Exp TInt16 Add :: Exp TInt16 -> Exp TInt16 -> Exp TInt16 -- Assumed semantics: fun x = x + 2 -- The following line must be uncommented to compile without errors -- fun :: Exp (TFun (TSeqCons TInt16 TSeqEmpty) TInt16) fun = Decl $ \(SeqCons x SeqEmpty) -> Add (Int16 2) x -- eval (Int16 x) = x -- eval (Call (Decl f) seq) = eval (f seq) -- eval (Add x y) = eval x + eval y -- test = eval $ Call fun (SeqCons (Int16 3) SeqEmpty) ----------------- There is full error message: ---------------------------- TestExp.hs:30:53: Could not deduce (w ~ 'TInt16) from the context (args ~ TSeqCons w v) bound by a pattern with constructor SeqCons :: forall (w :: TypeExp) (v :: TSeq). Exp w -> Seq v -> Seq (TSeqCons w v), in a lambda abstraction at TestExp.hs:30:16-33 or from (v ~ 'TSeqEmpty) bound by a pattern with constructor SeqEmpty :: Seq 'TSeqEmpty, in a lambda abstraction at TestExp.hs:30:26-33 `w' is a rigid type variable bound by a pattern with constructor SeqCons :: forall (w :: TypeExp) (v :: TSeq). Exp w -> Seq v -> Seq (TSeqCons w v), in a lambda abstraction at TestExp.hs:30:16 Expected type: Exp 'TInt16 Actual type: Exp w In the second argument of `Add', namely `x' In the expression: Add (Int16 2) x

2 2

"branching" conduits
by Simon Marechal 31 Jan '13

31 Jan '13

Hello, I have found the Conduit abstraction to be very well suited to a set of problems I am facing. I am however wondering how to implement "branching" conduits, and even conduit pools. I am currently in the process of rewriting parts (the simple parts) of the Logstash tool. There is a sample program that I use here: https://github.com/bartavelle/hslogstash/blob/deprecateUtils/examples/Redis… As it can be seen, it uses a "Redis" source, a conduit that decodes the JSON ByteString into a LogstashMessage, a conduit that stores it into Elasticsearch and outputs the result of that action as an Either, and finally a sink that prints the errors. My problem is that I would like more complex behaviour. For example, I would like to route messages to another server instead of putting them into Elasticsearch when the LogstashMessage has some tag set. But this is just an example, and it is probable I will want much more complex behavior soon. I am not sure how to proceed from here, but have the following ideas: * investigate how the Conduits are made internally to see if I can create a operator similar to $$, but that would have a signature like: Source m (Either a b) -> Sink a m r -> Sink b m r and would do the branching in a binary fashion. I am not sure this is even possible. * create a "mvars" connectors constructor, which might have a signature like this: Int -- ^ branch count (LogstashMessage -> Int) -- ^ branching function (Sink LogstashMessage m (), [Source m LogstashMessage]) -- ^ a suitable sink, several sources for the other conduits it would internally create a MVar (Maybe LogstashMessage) for each branch, and put putMVar accordingly to the branching function. When the Conduit is destroyed, it will putMVar Nothing in all MVars. the sources would takeMVar, check if it is Nothing, or just proceed as expected. The MVar should guarantee the constant space property, but there is the risk of inter branch blocking when one of the branches is significantly slower than the others. It doesn't really matter to me anyway. And all the branch Sinks would have to have some synchronization mechanism so that the main thread waits for them (as they are going to be launched by a forkIO). This is the simplest scheme I have thought of, and it is probably not a very good one. I am very interested in suggestions here.

3 3

Announcement - Haskell User Group Frankfurt
by Peter Althainz 31 Jan '13

31 Jan '13

Dear Haskellers, for all who are located near Frankfurt, there is a new Meetup kicked off: http://www.meetup.com/Frankfurt-Haskell-User-Group regards Peter Althainz

1 0

FFI - Approaches to C/C++
by Casey Basichis 31 Jan '13

31 Jan '13

Hi, I'm working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc. I've read this http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a number of other haskell posts suggesting the OOP is not the way to go. Without trying to emulate functional programming through templates or boost::phoenix, what approaches do you all favor when designing parts of an application in C++? Patterns to embrace or avoid? Should I just use functions and handle things with name spaces? I was thinking about handling the callbacks with boosts signals and slots 2 I know this is not entirely haskell centric, but it is a question for haskell users. Thanks, Casey -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasichis(a)gmail.com 310.387.7540

3 2

Re: [Haskell-cafe] FFI - Approaches to C/C++
by Casey Basichis 31 Jan '13

31 Jan '13

Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so "difficult" several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With "That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there." What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. >Casey Basichis <caseybasichis at gmail.com> wrote: > >> I'm not entirely sure what you mean. >> >> I'm intending on using Ogre for GUI - for which there is the Hogre >> bindings, but after emailing the DEV about it, I didn't get the >> impression from his advice that I should be using it for production >> code. Here is what he suggested: >> >> "It depends, really. Hogre is good for running Ogre from within >> Haskell, but it has its limitations. The number one thing people have >> been struggling with is handling input with hogre - there's Hois >> (Haskell wrapper for OIS) but it's not perfect (it misses input >> events), and the other option is having to write some C++ glue. Hogre >> is a solid proof of concept and you can do some demos with it, but if >> you're e.g. writing a game it might be a bit of a struggle. In the end >> it's about how much you value being able to write code in Haskell (or >> how allergic to C++ you are)." >> >> I'm on iOS so I imagine those difficulties are compounded. >> >> I am using several other C++ libraries for which there are no existing >> bindings and no Haskell alternative packages that are even remotely >> close. >> >> Are you suggesting it would be better to write all my own FFI bindings >> for all the needed libraries? > >That's not what I'm suggesting. It was just too little information to >properly judge the difficulty of doing everything in Haskell. > >Binding to Ogre (or C++ in general) is indeed difficult. If Hogre >doesn't work or is too limited, your best option might be to write a C >wrapper around the Hogre functionality you need. Another option is to >use SDL/OpenGL directly, which may be easier or harder depending on your >application. > >However, if you can build the bridge between your rendering library and >Haskell, then Haskell is certainly the better choice. > > >> Everything I read suggests that Haskells strengths are in >> transformation and that interaction is not its strong suit. >> >> I am interested in your thoughts and I am open to whatever, but you >> are the first to suggest that the mix is a bad idea. > >That used to be true, but the reason has nothing to do with the >language. The problem was that the libraries weren't there. Nowadays >you can write all sorts of interactive applications in Haskell, >including GUIs, TUIs, games, simulations and web applications. However, >I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm >afraid that it's not going to happen any time soon. > >Ultimately it's your choice. Let me summarize the possiblities: > > * C wrapper around Ogre. Easy integration, but need to write the > rendering code in C/C++. > > * Full FFI bindings to Ogre. Difficult integration, but you can write > your rendering code in Haskell. > > * Partial FFI bindings to Ogre. Integration may be somewhat easy, if > you do the initialization in Haskell and the actual rendering in > C/C++. However, this again requires to write the rendering in > C/C++. > > * Using SDL/OpenGL directly: Everything available for Haskell. May > be difficult, because you need to write OpenGL code. > >I hope, this helps. > > >Greets, >Ertugrul -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasichis(a)gmail.com 310.387.7540

2 1

(no subject)
by Casey Basichis 31 Jan '13

31 Jan '13

Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so "difficult" several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With "That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there." What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. >Casey Basichis <caseybasichis at gmail.com> wrote: > >> I'm not entirely sure what you mean. >> >> I'm intending on using Ogre for GUI - for which there is the Hogre >> bindings, but after emailing the DEV about it, I didn't get the >> impression from his advice that I should be using it for production >> code. Here is what he suggested: >> >> "It depends, really. Hogre is good for running Ogre from within >> Haskell, but it has its limitations. The number one thing people have >> been struggling with is handling input with hogre - there's Hois >> (Haskell wrapper for OIS) but it's not perfect (it misses input >> events), and the other option is having to write some C++ glue. Hogre >> is a solid proof of concept and you can do some demos with it, but if >> you're e.g. writing a game it might be a bit of a struggle. In the end >> it's about how much you value being able to write code in Haskell (or >> how allergic to C++ you are)." >> >> I'm on iOS so I imagine those difficulties are compounded. >> >> I am using several other C++ libraries for which there are no existing >> bindings and no Haskell alternative packages that are even remotely >> close. >> >> Are you suggesting it would be better to write all my own FFI bindings >> for all the needed libraries? > >That's not what I'm suggesting. It was just too little information to >properly judge the difficulty of doing everything in Haskell. > >Binding to Ogre (or C++ in general) is indeed difficult. If Hogre >doesn't work or is too limited, your best option might be to write a C >wrapper around the Hogre functionality you need. Another option is to >use SDL/OpenGL directly, which may be easier or harder depending on your >application. > >However, if you can build the bridge between your rendering library and >Haskell, then Haskell is certainly the better choice. > > >> Everything I read suggests that Haskells strengths are in >> transformation and that interaction is not its strong suit. >> >> I am interested in your thoughts and I am open to whatever, but you >> are the first to suggest that the mix is a bad idea. > >That used to be true, but the reason has nothing to do with the >language. The problem was that the libraries weren't there. Nowadays >you can write all sorts of interactive applications in Haskell, >including GUIs, TUIs, games, simulations and web applications. However, >I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm >afraid that it's not going to happen any time soon. > >Ultimately it's your choice. Let me summarize the possiblities: > > * C wrapper around Ogre. Easy integration, but need to write the > rendering code in C/C++. > > * Full FFI bindings to Ogre. Difficult integration, but you can write > your rendering code in Haskell. > > * Partial FFI bindings to Ogre. Integration may be somewhat easy, if > you do the initialization in Haskell and the actual rendering in > C/C++. However, this again requires to write the rendering in > C/C++. > > * Using SDL/OpenGL directly: Everything available for Haskell. May > be difficult, because you need to write OpenGL code. > >I hope, this helps. > > >Greets, >Ertugrul

1 0

list comprehansion performance has hug different
by Junior White 31 Jan '13

31 Jan '13

Hi Cafe, I have two programs for the same problem "Eight queens problem", the link is http://www.haskell.org/haskellwiki/99_questions/90_to_94. My two grograms only has little difference, but the performance, this is my solution: -- solution 1------------------------------------------------------------ queens1 :: Int -> [[Int]] queens1 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | q <- [1..n], qs <- queens' (k-1), isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist, q) -> abs (try - q) == colDist) $ zip [1..] qs -- solution 2-------------------------------------------------------------- queens2 :: Int -> [[Int]] queens2 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | qs <- queens' (k-1), q <- [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist,q) -> abs (try - q) == colDist) $ zip [1..] qs the performance difference is: (set :set +s in ghci) *Main> length (queens1 8) 92 (287.85 secs, 66177031160 bytes) *Main> length (queens2 8) 92 (0.07 secs, 17047968 bytes) *Main> The only different in the two program is in the first is "q <- [1..n], qs <- queens' (k-1)," and the second is "qs <- queens' (k-1), q <- [1..n]". Does sequence in list comprehansion matter? And why?

9 16

Haskell Weekly News: Issue 256
by Daniel Santa Cruz 31 Jan '13

31 Jan '13

Welcome to issue 256 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the weeks of January 20 to 26, 2013. Quotes of the Week * elliott: cmccann: unfortunately it is too perfect an abstraction to be useful. * SamanthaD: shachaf: you're one of those dirty imperative communists who want the state to dictate everything! * monochrom: I refuse camel case and mark zuckerberg. same level. not negotiable. * mauke: a newtype is like an existing type but wearing glasses and a fake mustache and a sign saying "you've never seen me before" Top Reddit Stories * Taking magic out of GHC or: Tracing compilation by transformation (intro to Core transformations, inlining,.. Domain: ics.p.lodz.pl, Score: 59, Comments: 2 On Reddit: [1] http://goo.gl/lJmsb Original: [2] http://goo.gl/IbJ5O * Introduction to Haskell IO Domain: haskellforall.com, Score: 57, Comments: 26 On Reddit: [3] http://goo.gl/fPky4 Original: [4] http://goo.gl/Xymbr * The longest type signature I have ever seen (package Nussinov78) Domain: i.imgur.com, Score: 48, Comments: 26 On Reddit: [5] http://goo.gl/ePwNs Original: [6] http://goo.gl/B74yW * There is now a patch for the GHC runtime system which implements a scheduler which can handle threads with priorities. Domain: hackage.haskell.org, Score: 47, Comments: 12 On Reddit: [7] http://goo.gl/22XgH Original: [8] http://goo.gl/8iC8w * Success story: novice haskeller moves console cursor with “netwire” FRP library Domain: danbst.wordpress.com, Score: 43, Comments: 8 On Reddit: [9] http://goo.gl/dm8ga Original: [10] http://goo.gl/Ue7pK * Haskell as pseudo code Domain: arxiv.org, Score: 33, Comments: 2 On Reddit: [11] http://goo.gl/JL8Mf Original: [12] http://goo.gl/5D4zV * Generalizing do notation Domain: self.haskell, Score: 28, Comments: 19 On Reddit: [13] http://goo.gl/teYAD Original: [14] http://goo.gl/teYAD * Tutorial: Up-front Unit Testing in Haskell Domain: github.com, Score: 26, Comments: 21 On Reddit: [15] http://goo.gl/kjzYJ Original: [16] http://goo.gl/oB2jg * The Design of a Practical Proof Checker for a Lazy Functional Language [PDF] Domain: people.cs.missouri.edu, Score: 26, Comments: On Reddit: [17] http://goo.gl/sj5Aj Original: [18] http://goo.gl/eEUOj * Introduction to Haskell, Lecture 2 is Live Domain: shuklan.com, Score: 24, Comments: 4 On Reddit: [19] http://goo.gl/1nUVv Original: [20] http://goo.gl/rCbfx * Hugs in your browser Domain: tryhaskell.org, Score: 24, Comments: 21 On Reddit: [21] http://goo.gl/zNtex Original: [22] http://goo.gl/wMPPW * Free functors - the reason Free and operational are not equivalent Domain: self.haskell, Score: 24, Comments: 12 On Reddit: [23] http://goo.gl/E7qe7 Original: [24] http://goo.gl/E7qe7 * Scribbling, smudging and smearing with Haskell Domain: self.haskell, Score: 22, Comments: 108 On Reddit: [25] http://goo.gl/KBw0V Original: [26] http://goo.gl/KBw0V * Touch and Keyboard API (announcing Elm 0.7.1) Domain: elm-lang.org, Score: 20, Comments: 3 On Reddit: [27] http://goo.gl/OhFaH Original: [28] http://goo.gl/rV9bU * (re)implementing the generalised Functor strength function using lenses. Domain: statusfailed.com, Score: 20, Comments: 3 On Reddit: [29] http://goo.gl/gEYHr Original: [30] http://goo.gl/TDX2A Top StackOverflow Questions * Can using UndecidableInstances pragma locally have global consequences on compilation termination? votes: 20, answers: 1 Read on SO: [31] http://goo.gl/PcQF1 * Why doesn't GHC Haskell support overloaded record parameter names? votes: 14, answers: 1 Read on SO: [32] http://goo.gl/BJ71T * How much does it cost for Haskell FFI to go into C and back? votes: 14, answers: 2 Read on SO: [33] http://goo.gl/kUCKn * Compile unsafe Haskell votes: 13, answers: 1 Read on SO: [34] http://goo.gl/nGaCX * Why GADT/existential data constructors cannot be used in lazy patterns? votes: 12, answers: 2 Read on SO: [35] http://goo.gl/zhpCh * Correct design for Haskell exception handling votes: 11, answers: 2 Read on SO: [36] http://goo.gl/zeWoH * How to use phase control of inlining in haskell? votes: 10, answers: 0 Read on SO: [37] http://goo.gl/dyuGI * Looking for resources that help testing a Haskell implementation for standard conformance votes: 9, answers: 1 Read on SO: [38] http://goo.gl/DL7vY * Generate a C struct based on a complex Haskell type votes: 8, answers: 1 Read on SO: [39] http://goo.gl/7E8OT * How to structure a Haskell project? votes: 7, answers: 1 Read on SO: [40] http://goo.gl/J4GuA * Difference between two functions creating a singleton list votes: 7, answers: 3 Read on SO: [41] http://goo.gl/ZXzw0 Until next time, Daniel Santa Cruz References 1. http://ics.p.lodz.pl/~stolarek/blog/2013/01/taking-magic-out-of-ghc-or-trac… 2. http://www.reddit.com/r/haskell/comments/17bu54/taking_magic_out_of_ghc_or_… 3. http://www.haskellforall.com/2013/01/introduction-to-haskell-io.html 4. http://www.reddit.com/r/haskell/comments/17712e/introduction_to_haskell_io/ 5. http://i.imgur.com/Zv9JH9A.png 6. http://www.reddit.com/r/haskell/comments/178jwh/the_longest_type_signature_… 7. http://hackage.haskell.org/trac/ghc/ticket/7606 8. http://www.reddit.com/r/haskell/comments/1725g0/there_is_now_a_patch_for_th… 9. http://danbst.wordpress.com/2013/01/23/novice-netwire-user/ 10. http://www.reddit.com/r/haskell/comments/173cxi/success_story_novice_haskel… 11. http://arxiv.org/abs/1301.5076 12. http://www.reddit.com/r/haskell/comments/176xk0/haskell_as_pseudo_code/ 13. http://www.reddit.com/r/haskell/comments/16zrsp/generalizing_do_notation/ 14. http://www.reddit.com/r/haskell/comments/16zrsp/generalizing_do_notation/ 15. https://github.com/kazu-yamamoto/unit-test-example/blob/master/markdown/en/… 16. http://www.reddit.com/r/haskell/comments/1750i9/tutorial_upfront_unit_testi… 17. http://people.cs.missouri.edu/~harrisonwl/papers/tfp2012.pdf 18. http://www.reddit.com/r/haskell/comments/179367/the_design_of_a_practical_p… 19. http://shuklan.com/haskell 20. http://www.reddit.com/r/haskell/comments/172h5q/introduction_to_haskell_lec… 21. http://tryhaskell.org/hugs/ 22. http://www.reddit.com/r/haskell/comments/177a56/hugs_in_your_browser/ 23. http://www.reddit.com/r/haskell/comments/17a33g/free_functors_the_reason_fr… 24. http://www.reddit.com/r/haskell/comments/17a33g/free_functors_the_reason_fr… 25. http://www.reddit.com/r/haskell/comments/175mxw/scribbling_smudging_and_sme… 26. http://www.reddit.com/r/haskell/comments/175mxw/scribbling_smudging_and_sme… 27. http://elm-lang.org/blog/announce/version-0.7.1.elm 28. http://www.reddit.com/r/haskell/comments/179nwl/touch_and_keyboard_api_anno… 29. http://statusfailed.com/blog/2013/01/26/haskells-strength-generalising-with… 30. http://www.reddit.com/r/haskell/comments/17b5ak/reimplementing_the_generali… 31. http://stackoverflow.com/questions/14476230/can-using-undecidableinstances-… 32. http://stackoverflow.com/questions/14422169/why-doesnt-ghc-haskell-support-… 33. http://stackoverflow.com/questions/14519905/how-much-does-it-cost-for-haske… 34. http://stackoverflow.com/questions/14429966/compile-unsafe-haskell 35. http://stackoverflow.com/questions/14538255/why-gadt-existential-data-const… 36. http://stackoverflow.com/questions/14538294/correct-design-for-haskell-exce… 37. http://stackoverflow.com/questions/14446368/how-to-use-phase-control-of-inl… 38. http://stackoverflow.com/questions/14484569/looking-for-resources-that-help… 39. http://stackoverflow.com/questions/14500582/generate-a-c-struct-based-on-a-… 40. http://stackoverflow.com/questions/14421178/how-to-structure-a-haskell-proj… 41. http://stackoverflow.com/questions/14530555/difference-between-two-function… 42. https://plus.google.com/105107667630152149014/about

1 0

TIPS: To Insure Package Sanity
by Albert Y. C. Lai 31 Jan '13

31 Jan '13

If you possess multiple instances (may be different versions, may be same version different builds) of a package, life can be hard and confusing. The problems are explained in my http://www.vex.net/~trebla/haskell/sicp.xhtml and faced by many people regularly. (Just read this mailing list.) cabal-install has a mechanism for not adding more instances. It is available since version 0.14.0, or earlier. It is just little known. It is also a bit manual. You have to give 1 instruction for each package. If you want to say it for n packages, you have to give n instructions. Also, if you give such an instruction for a package you do not already have, there is a problem: now you can't install that package. To insure package sanity, add these lines to your $HOME/.cabal/config, one line per package you want to protect. (Cannot merge into one line.) constraint: array installed constraint: bytestring installed constraint: Cabal installed constraint: containers installed ... Generally, do it for every package that comes with GHC, and every package that comes with the Haskell Platform if you have it, plus every package that you want stable. (You may omit packages that cannot possibly be on hackage, e.g., integer-gmp.) Remember to revise those lines whenever you switch GHC versions or Haskell Platform versions, since their package lists change. Alternatively, if you want even more manual work (in exchange for more fine-tuning perhaps?): every time you use "cabal install": cabal install --constraint="array installed" --constraint="bytestring installed" --constraint="Cabal installed" --constraint="containers installed" ...

1 0