- Haskell-Cafe - Haskell.org

Best approach to avoid dependency hells
by Ivan Perez 08 Dec '12

08 Dec '12

Hello everyone, I've spent the last couple of days fighting my way around a dependency hell with my own libraries and packages. If I install them package by package (by hand), I'm very likely to hit one of these conflicts that I'm talking about. A simple example of something that did happen: - Package A depends on bytestring, and is compatible with both 0.9.* and 0.10.* - Package B depends on ghc, which I installed using the package manager and which depends on bytestring 0.9.2 - Package B depends on package A. I do not want to add to the cabal files that B depends on bytestring 0.9.*, because it's not true, or that A depends on bytstring 0.9, because it's also not true. I would like to the best approach to 1) avoid these situations and 2) fix them when they happen. Regarding (2), Is there any way to automatically rebuild all the broken packages? Regarding (1), I thought about using cabal-dev, but I think I'll just have the same problem, won't I? After all, I started from a clean fresh ghc installation and I just installed what I needed to make my program run. I also thought about adding process, bytestring and other global packages to the list of constraints in ~/.cabal/config. Would this be a good approach, or will it lead to bigger headaches in the future (for instance, in the form of programs that just cannot be installed at all)? Also, is there any way to detect potential dependency hells without having to install a package? (Some tool that will analyse the dependency information (statically) and determine more strict or incorrect upper and lower bounds for the dependencies of a package.) Cheers, Ivan

5 7

Safe Haskell safe-inferred status
by Omari Norman 08 Dec '12

08 Dec '12

Is there a way to determine whether a module has been marked safe by GHC for purposes of Safe Haskell? The GHC 7.4 docs say that if I compile a module and I don't use the -XSafe or -XTrustworthy flag, GHC will automatically figure out whether the module would have compiled with -XSafe and, if so, marks the module as safe. Where does GHC record this determination? It doesn't seem to show up in ghc-pkg dump (there you can see trusted packages, but I am looking for safe-inferred status for modules.) ghc --show-iface seems to come up dry too. I know Haddock shows this information but sometimes it says "Safe Haskell: None". I have no idea what this means so I was wondering what GHC itself says. Thanks. --Omari

2 1

Understanding GHC's instance inference.
by Takayuki Muranushi 08 Dec '12

08 Dec '12

Dear everyone, I have a code https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11-… that produces a type-error when I remove a type signature. https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11.… The strange point is the following error message from ghc 7.6.1 (abbreviated; the full error text is included as the comment of the code): No instance for (PType (Cons V.Vector (V.Vector Double) (Cons V.Vector (V.Vector Char) (Cons V.Vector (V.Vector Int) (Nil V.Vector)))) ((Double -> Char -> Int -> String) -> a0)) arising from a use of `forZN' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there is a potential instance available: instance [overlap ok] (Zip v, Reduce v f0 vaS r (Nil v)) => PType (Cons v (v i) vaS) ((i -> f0) -> v r) ghc presents only one potential instance, and it seems to me that by setting v = V.Vector i = Double f0 = Char -> Int -> String r = String etc, you can actually match the 'potential' instance. The fact that this code typechecks with an additional type signature (zipf-11-1.hs) shows that there is a way to satisfy the constraint. So the question: why the instance inference stops here, when there is only one potential instance and no ambiguity? Or is it? What are potential instances? I thought the cause of the error is that ghc cannot match (v r) with (a0), and so I tried to shrink the example before I post. However my guess was wrong. Tinyer example did typecheck: https://github.com/nushio3/practice/blob/master/instance-inference/copy-01.… https://github.com/nushio3/practice/blob/master/instance-inference/copy-02.… https://github.com/nushio3/practice/blob/master/instance-inference/copy-04.… If you have any sample codes that fails to typecheck and presents only one "potential instance" , that will be a great clue for me. Also, please recommend me any reading material for instance inference. (Haskell 98 deals with instance declaration syntax, and there are variety of text for type inference, but I could find few for instance inference.) Best, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

2 2

Maintainer of fixpoint
by Petr P 07 Dec '12

07 Dec '12

Dear Haskellers, I've made some minor improvements of fixpoint package < http://hackage.haskell.org/package/fixpoint>. I tried to contact the original maintainer twice, but without success. The package hasn't been updated for 4 years. How should I proceed? Should I start a new fork of the package? Or is there a way how to take over an orphaned package? Thanks for help, Petr Pudlak

3 3

yaml and aeson Was: Growing Haskell Platform
by Michael Snoyman 07 Dec '12

07 Dec '12

On Fri, Dec 7, 2012 at 10:54 AM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > * Michael Snoyman <michael(a)snoyman.com> [2012-12-07 09:52:07+0200] > > Let me bring up one other package: yaml (written by me). I think it's a > > pretty good fit for the standard YAML packaging library, since it simply > > reuses the existing infrastructure from the aeson package (i.e. the > ToJSON > > and FromJSON typeclasses, and the Value datatype). But I'm actually a bit > > concerned about proposing it, based on some history. > > When I was looking at existing YAML libraries, I rejected yours when I > saw JSON types. (I did see the "do not let that confuse you, it's > intentional" warning, and no, it didn't help.) > > Besides giving the feeling that the API is a hack, this will inevitably > confuse readers of my code who are not familiar with the library and, > just based on the names, will assume that the code is working with JSON, > not YAML. > > If you mean the naming is a hack, I agree. But if we pretend for a moment that the word JSON was actually replaced with YAML everywhere, I think the abstraction is correct. The Value datatype represents a very sane subset of YAML that people usually want to deal with. And if they want to deal with all the glories of aliases and tags, we still have the Text.Libyaml interface which preserves all information. In other words, the hack is in the name, not the abstraction. > IIUC, "all of the existing tools for JSON processing" are mainly just > existing FromJSON instances. I am not sure how common this situation is, > but for that you could define a newtype whose FromYAML instance would > internally use the FromJSON instance of the underlying type. > > It's the two typeclasses and the Value datatype. Don't underestimate the importance of reusing infrastructure here. If we had our own types and classes in YAML, then everyone who wants to include serialization classes in their packages would have to write redundant instances for both packages. Most likely, that would just mean incomplete instances for both packages. It would also mean that we'd have to duplicate libraries like aeson-lens, and duplicate all bugfixes in built-in instances, Generics code, TH code, etc. As a side benefit, the current setup allows code to remain serialization-format-agnostic. For example, Persistent can read configuration from either JSON to YAML files. Since YAML is a superset of JSON, that's not such an amazing statement, but it does mean that users can avoid an extra yaml package dependency if they really are just sticking with JSON data. > Or perhaps the JSON-agnostic subset of aeson could be extracted into a > separate library, which both aeson and yaml would depend on. > > I'd be very much in favor of that. I'm not so irked by the "name hack" to have bothered bringing this up with Bryan, but if he's willing to make that change, I'd certainly be grateful. I actually think it would be more logical for the typeclasses to be called ToValue and FromValue anyway, since that more directly states what they do. > As for toYAML/toJSON, I guess most of the time they are different anyway — > otherwise it's defeating the purpose of YAML to be more human-readable > than JSON. > > I don't think that's true in practice. Most of the readability of YAML comes from the syntax, not the choice of actual serialization structure. But I could be mistaken. Michael

2 2

schedule function
by Corentin Dupont 06 Dec '12

06 Dec '12

Hi all, I have a simple question: is there in the libraries a function that can schedule a variable list of events for me? For example of the type: type Schedule = [UTCTime, IO()] startSchedule :: TVar Schedule -> IO ThreadId The function startSchedule will have to execute my actions at the given times. Of course the TVar can be changed by another thread, so the schedule will have to be recomputed. Thanks! Corentin

1 0

Generics & pattern matching
by Joerg Fritsch 06 Dec '12

06 Dec '12

I have the code below that I pluged from SO. My problem is that although I sort of understand how with rewrite True and rewrite False it is suppressed that always the first element of the tuple stays as-is; I cannot find any way to apply this to the last element also. In essence there are times when I would need to change all elements of the tuple but the first and at other times I would need to change all elements except the first and the last. I don't quite understand (yet) how I could do that. Is there any way to match for a specific element eg. the third from the right or so? --Joerg {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import Data.Typeable import GHC.Generics rewrite_ :: (Generic a, Generic b, Rewriter (Rep a), Rewrite (Rep a) ~ Rep b) => a -> b rewrite_ = to . rewrite False . from class Rewriter f where type Rewrite f :: * -> * rewrite :: Bool -> f a -> (Rewrite f) a instance Rewriter f => Rewriter (M1 i c f) where type Rewrite (M1 i c f) = M1 i c (Rewrite f) rewrite x = M1 . rewrite x . unM1 instance Typeable c => Rewriter (K1 i c) where type Rewrite (K1 i c) = K1 i String rewrite False (K1 x) | Just val <- cast x = K1 val rewrite _ _ = K1 "NIL" instance (Rewriter a, Rewriter b) => Rewriter (a :*: b) where type Rewrite (a :*: b) = Rewrite a :*: Rewrite b rewrite x (a :*: b) = rewrite x a :*: rewrite True b y0 :: (String, Int, Double) y0 = ("something", 3, 4.788) y1 :: (String, String, String, (Int, Int)) y1 = ("something else", "Hello", "NIL", (4,6)) main :: IO () main = do print (rewrite_ y0 :: (String, String, String)) print (rewrite_ y1 :: (String, String, String, String))

2 1

Are there REPA linear algebra routines? e.g. Eigenvalues?
by KC 06 Dec '12

06 Dec '12

:) -- -- Regards, KC

2 1

The end of an era, and the dawn of a new one
by Simon Peyton-Jones 06 Dec '12

06 Dec '12

Friends You'll have seen Simon Marlow's recent announcement (included below): | Today I'm announcing that I'm leaving Microsoft Research. Simon Marlow and I have worked together on GHC for nearly two decades. During much of that time we have shared a cup of coffee every morning (one cup each, since you ask), to discuss what's going on in GHC-land. We had frequent detailed and illuminating debates about design alternatives. Simon is the absolute master of GHC's code generation, runtime system, garbage collector, support for parallel execution, and much else besides. His sheer programming skill in rooting out obscure and hard-to-reproduce runtime system bugs has always amazed me. He is more than just a great hacker, of course. He is a leader in our community, has a strong publication record, chaired the Haskell Prime committee for a year, and is sought after for tutorials about parallel programming. I owe Simon a great debt, as I think we all do, for the care and skill he has lavished on GHC. He's not going to disappear entirely, but he will be spending much less time on GHC than in the past. That is a change, but it's a change that was always going to happen sometime, and while change is sometimes uncomfortable, it can also open up new possibilities. GHC is over 20, and like my own children (who are actually all a bit younger than GHC), that's not a bad time to start to head out into the world. Over time, more and more people have started to help with the task of developing and maintaining GHC. We'll have to do more of that. These days GHC has a very large "surface area" (running on different platforms, dynamic linking, debugger, profiler, GHCi, libraries and Cabal, etc etc), and has grown far beyond what any single person or research group can manage. Lest you should wonder, I myself will certainly continue to work on GHC. But my job is to be a *researcher*, and I am not well equipped -- in temperament or expertise -- to deal with the myriad complexities of deployment, upgrade policy, portability, and the like. Well Typed (mostly in the guise of Ian Lynagh) will continue to handle some of these issues, but again there is too much for one person to do. So we need your help. Seriously. Rather than just thinking "GHC HQ will sort it out", I would welcome you saying "Shall I take responsibility for X?". Johan, Bryan, and others offering to be GHC Performance Tsars is a great recent example. But don't wait to be asked: just make an offer if you see a gap or an open ticket --- and I think there will be plenty of those. Particularly valuable are offers to take responsibility for a particular area (eg the LLVM code generator, or the FFI). I'm hoping that this sea change will prove to be quite empowering, with GHC becoming more and more a community project, more resilient with fewer single points of failure. I am going to miss that cup of coffee though. Thank you Simon! Facebook is lucky to have you. Onward and upward. Simon (PJ) | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of Simon Marlow | Sent: 22 November 2012 11:27 | To: haskell; glasgow-haskell-users(a)haskell.org | Subject: Leaving Microsoft | | Today I'm announcing that I'm leaving Microsoft Research. | | My plan is to take a break to finish the book on Parallel and Concurrent | Haskell for O'Reilly, before taking up a position at Facebook in the UK | in March 2013. | | This is undoubtedly a big change, both for me and for the Haskell | community. I'll be stepping back from full-time GHC development and | research and heading into industry, hopefully to use Haskell. It's an | incredibly exciting opportunity for me, and one that I hope will | ultimately be a good thing for Haskell too. | | What does this mean for GHC? Obviously I'll have much less time to work | on GHC, but I do hope to find time to fix a few bugs and keep things | working smoothly. Simon Peyton Jones will still be leading the project, | and we'll still have support from Ian Lynagh, and of course the | community of regular contributors. Things are in a reasonably stable | state - there haven't been any major architectural changes in the RTS | lately, and while we have just completed the switchover to the new code | generator, I've been working over the past few weeks to squeeze out all | the bugs I can find, and I'll continue to do that over the coming months | up to the 7.8.1 release. | | In due course I hope that GHC can attract more of you talented hackers | to climb the learning curve and start working on the internals, in | particular the runtime and code generators, and I'll do my best to help | that happen. | | Cheers, | Simon

2 1

Maintainer of hgettext
by Ivan Perez 06 Dec '12

06 Dec '12

Hello haskellers, A few months ago I sent an email to Vasyl Pasternak regarding a couple of bugs in hgettext [1], together with a small patch that fixes them. I never received an answer and I can see that the error persists. Does anyone know where he is? What would you recommend at this point? Cheers, Ivan. [1] http://hackage.haskell.org/package/hgettext

3 3