December 2012 - Haskell-Cafe

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

Vector mysteries
by Fixie Fixie 06 Dec '12

06 Dec '12

Hi I am trying to implement Show for a storable-mutable-vector. Does anyone have a clue why the type-system is killing me :-) Code is below... Cheers Felix ---- {-# LANGUAGE ExistentialQuantification #-} import Control.Monad (liftM2) import qualified Data.Vector.Unboxed as V import qualified Data.Vector.Unboxed.Mutable as MV import Data.Vector.Storable.Mutable import GHC.Prim (RealWorld) import Control.Monad.Primitive import Control.Monad import qualified Data.Vector as VEC import qualified Data.Vector.Generic.Mutable as GM import Data.Int import Data.Typeable.Internal import Data.Primitive data Row = forall m s. (Storable s, MV.Unbox s, Prim s, PrimMonad m) => Row (MV.MVector (PrimState m) s) instance Show Row where show (Row row) = do let xx = MV.read row 0 "Done" main :: IO () main = do print "Done" I get this error: Could not deduce (PrimState m ~ PrimState m0) from the context (Storable s, MV.Unbox s, Prim s, PrimMonad m) bound by a pattern with constructor Row :: forall (m :: * -> *) s. (Storable s, MV.Unbox s, Prim s, PrimMonad m) => MV.MVector (PrimState m) s -> Row, in an equation for `show' NB: `PrimState' is a type function, and may not be injective Expected type: MV.MVector (PrimState m0) s Actual type: MV.MVector (PrimState m) s In the first argument of `MV.read', namely `row' In the expression: MV.read row 0

2 1

sequential logic
by Christopher Howard 06 Dec '12

06 Dec '12

Hi. I was wondering what the various (and especially most simple) approaches one could take for working with (simulating or calculating) sequential logic in Haskell. By sequential logic, I mean like wikipedia describes, where a system is made up of logic gates, whose output is dependent not only on the logic operation of the gate, but on the previous state of the gate. (Like in electronics where the system can be driven by a clock signal or have memory.) Does one have to get into FRP for that sort of thing? Or use some kind of FSM framework? Or is there some kind of fancy state monad suitable for that? Or...? I'm no electronic or digital engineer, but for learning purposes I've been trying to see if I could build an (extremely simple) virtual processor or calculator in Haskell, using only the Bool type and a few of the boolean operators (and functions composed of the aforementioned), reproducing things like half adders and full adders as functions in the program. Of course, I quickly ran into the stateful aspect of the problem, in subjects like clock signal and flip flops. -- frigidcode.com

3 2