October 2009 - Glasgow-haskell-users

GHC, CPP and stringize
by Neil Brown 30 Oct '09

30 Oct '09

Hi, The GHC manual says that if you pass -cpp to GHC, it runs the C preprocessor, "cpp" on your code before compilation (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html…) But why, in that case, does stringize not seem to work when the -cpp flag is given? In my example, test.hs is using the C preprocessor with a simple macro to trace functions with their name. Running GHC with -cpp gives an error, but if I run cpp on the file directly then feed it to GHC, I get no error: ===== *$ ghc --version* The Glorious Glasgow Haskell Compilation System, version 6.10.3 *$ cat test.hs* import Debug.Trace #define TR(f) (trace #f f) main :: IO () main = TR(putStrLn) "Hello!" *$ ghc -cpp --make test.hs* [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:6:14: Not in scope: `#' *$ cpp test.hs* # 1 "test.hs" # 1 "<built-in>" # 1 "<command-line>" # 1 "test.hs" import Debug.Trace main :: IO () main = (trace "putStrLn" putStrLn) "Hello!" *$ cpp test.hs > test-cpp.hs* *$ ghc -cpp --make test-cpp.hs* [1 of 1] Compiling Main ( test-cpp.hs, test-cpp.o ) Linking test-cpp ... *$ ./test-cpp* putStrLn Hello! ===== What am I missing? Thanks, Neil.

2 1

RE: [Template-haskell] How to extract name and type of exported functions in modules
by Simon Peyton-Jones 30 Oct '09

30 Oct '09

| First I thought I would examine the source code of template-haskell | (more specifically qLocation and qReify) to figure out how to do it | but got stuck. Obviously I have still much to learn when it comes to | Haskell. | | Could someone explain how Quasi works? Have you read the paper? Referred to from here http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.ht…, the particular bit you want is Section 10 of http://research.microsoft.com/~simonpj/papers/meta-haskell/notes2.ps | The only way this can work (as fast as I can see) is if where is | another instance of Quasi than Q and IO but I cannot find that | instance in the source code. Yes indeed there is -- the type checker monad! See TcSplice line 819. Simon

1 0

RE: Update on GHC 6.12.1
by Simon Peyton-Jones 29 Oct '09

29 Oct '09

| Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) Oh cruel, cruel, cruel! And unjustified to boot. My proposal (perhaps unclear) was exactly as Bulat suggests. However I'm sure we'll find some other way of breaking existing programs :-) Simon | -----Original Message----- | From: Lennart Augustsson [mailto:lennart.augustsson@gmail.com] | Sent: 29 October 2009 10:25 | To: Bulat Ziganshin | Cc: Simon Peyton-Jones; GHC users | Subject: Re: Update on GHC 6.12.1 | | Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) | | -- Lennart (iPhone) | | On 29 Oct 2009, at 03:33, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> | wrote: | | > Hello Simon, | > | > Thursday, October 29, 2009, 1:55:00 AM, you wrote: | > | >> Currently 'mdo' is enabled by -XRecursiveDo. So we propose to | >> deprecate this flag, with another flag -XDoRec to enable the 'rec' | >> keyword. | > | > i think the best way is to support both in 6.12, marking mdo usage as | > deprecated, and remove it in one of next versions | > | > -- | > Best regards, | > Bulat mailto:Bulat.Ziganshin@gmail.com | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

ghc hung by FunctionalDependencies/UndecidableInstances
by Roland Zumkeller 29 Oct '09

29 Oct '09

Hi, ghc seems to hang and eat memory when fed the following code: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-} class C a b | a -> b where f :: a -> b newtype T a = T a instance (C a b, Eq b) => Eq (T a) where (==) = undefined g x = (undefined :: a -> a -> a -> ()) (T x) (f x) (undefined :: Eq a => a) Is this a bug? Best, Roland -- http://alacave.net/~roland/

2 1

Coinductive proofs of type class instances
by Louis Wasserman 28 Oct '09

28 Oct '09

Hey all, There was a discussion<http://www.nabble.com/Resolving-overloading-loops-for-circular-constraint-g…>a while back about coinductive proofs of type class instances, discussing a problem I'd encountered independently, and worked out a rough solution to. I wanted to see if that solution had been reached by other people, and throw it into the mix. My problem is slightly different, though, so it may not generalize. First consider the problem that GHC doesn't allow type equality constraints in class definitions, so for example, > class (F a ~ b) => Foo a b In particular, if I wanted F a to be *uniquely* associated with A, I might say that > class (F a ~ b) => Foo a b | b -> a where > type F a As a result, F would be a *bijective type family*, enforced by the type system. Interestingly, the GHC docs suggest something like this as an implementation for functional dependencies in general: > class Foo a b | a -> b is equivalent to > class (F a ~ b) => Foo a b where > type Foo a except, of course, the latter isn't implemented in 6.10.4. All of this is idealized though: if GHC allowed equality constraints in superclass contexts, then this would be nice. Here was my workaround: a type class Foo is essentially a list of methods foo1 :: Foo a => ..... foo2 :: Foo a => ..... Of course, if there are superclass constraints on Foo a, those are implicitly included here. My thought was that > class (F a ~ b) => Foo a b where > foo1 :: (constraints1) => ... is essentially equivalent to > class Foo a b where > foo1 :: (F a ~ b, contraints1) => ... save that everywhere we encounter a (Foo a b) constraint, we replace it with (Foo a b, F a ~ b). Now, of course, we might have a (Foo a b) constraint in another superclass context, and have to recurse. That might even be fine, though I haven't worked it out. For this particular example, though, (Foo a (F a)) is equivalent to (F a ~ b, Foo a b). This approach actually, I think, works out some coinductive issues, if we apply this approach to issues besides type equality constraints. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

1 0

ghc search paths (like CPATH for gcc)
by Misha Aizatulin 28 Oct '09

28 Oct '09

Hello, is there a mechanism for ghc similar to setting the CPATH variable for gcc? I'd like ghc to look in the given list of paths every time it compiles something, without me having to retype the flags. For ghci there is .ghci, but it gets ignored when I run ghc. Best, Misha

2 2

Type checker's expected and inferred types (reformatted)
by C Rodrigues 25 Oct '09

25 Oct '09

(Some formatting was apparently lost en route. Trying again with extra newlines.) I came across a type error that misled me for quite a while, because the expected and inferred types were backwards (from my point of view). A simplified example is below. Can someone explain how GHC's type checker creates the error message? In this example, fun1 and fun2 are basically the same. The type error is because they try to run an IO () together with a Maybe (). > import Control.Monad > > foo :: Maybe () > foo = return () > > bar :: IO () > bar = return () > > fun1 = let fooThen m = foo>> m > in fooThen (bar>> undefined) > > fun2 = let fooThen m = foo>> m > in fooThen (do {bar; undefined}) With ghc 6.10.4, both functions attribute the error message to `bar'. However, the expected and inferred monads are swapped. fun1 produces the error message: Couldn't match expected type `Maybe a' against inferred type `IO ()' In the first argument of `(>>=)', namely `bar' fun2 produces the error message: Couldn't match expected type `IO ()' against inferred type `Maybe ()' In a stmt of a 'do' expression: bar It's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO (). _________________________________________________________________ Windows 7: Simplify your PC. Learn more. http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WL…

6 8

Type checker's expected and inferred types (reformatted)
by C Rodrigues 24 Oct '09

24 Oct '09

> Which message do you prefer? I couldn't tell which it was. I prefer fun1. In my understanding, the 'inferred' type is gleaned by looking at theexpression itself, while the 'expected' type is implied by the context. _________________________________________________________________ Windows 7: It works the way you want. Learn more. http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WL…

1 0

Type checker's expected and inferred types
by C Rodrigues 23 Oct '09

23 Oct '09

I came across a type error that misled me for quite a while, because the expected and inferred types were backwards (from my point of view). A simplified example is below. Can someone explain how GHC's type checker creates the error message? In this example, fun1 and fun2 are basically the same. The type error is because they try to run an IO () together with a Maybe (). > import Control.Monad>> foo :: Maybe ()> foo = return ()>> bar :: IO ()> bar = return ()>> fun1 = let fooThen m = foo >> m> in fooThen (bar >> undefined)>> fun2 = let fooThen m = foo >> m> in fooThen (do {bar; undefined}) With ghc 6.10.4, both functions attribute the error message to `bar'. However, the expected and inferred monads are swapped.fun1 produces the error message:Couldn't match expected type `Maybe a' against inferred type `IO ()'In the first argument of `(>>=)', namely `bar'fun2 produces the error message:Couldn't match expected type `IO ()' against inferred type `Maybe ()'In a stmt of a 'do' expression: bar It's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO (). _________________________________________________________________ New Windows 7: Find the right PC for you. Learn more. http://www.microsoft.com/windows/pc-scout/default.aspx?CBID=wl&ocid=PID2472…

2 1

how can I get a listing of everything that's done in a program
by Ralph Crawford 22 Oct '09

22 Oct '09

Hi. I'm working with GHC 6.10.4 on Solaris. I'm new at Haskell and have inherited a rather large and complex program to maintain and modify. I'd like to get a listing of everything - every single step - that's done in a run of the program. Something similar to the output of the :step command, but I'd like the entire run (which would involve tens of thousands of steps). Is there a way to just do this - have it run and print everything it does to the screen? I've tried doing the following, after starting a "script" to capture all of the screen output... ghci -fglasgow-exts parsequery.hs :break 36 main which takes me to this prompt... Loading package mtl-1.1.0.2 ... linking ... done. Stopped at lesearch.hs:36:13-39 _result :: IO SearchState = _ input :: [String] = _ st :: SearchState = _ [lesearch.hs:36:13-39] *Main> This takes me to the call before the one that I want to output each step of so that I can then manually, with hardcopy, read it and get an idea of what happened. So I start a step through the next call. [lesearch.hs:36:13-39] *Main> :step process_query_loop st input Stopped at lesearch.hs:(46,0)-(69,39) _result :: IO SearchState = _ ... [lesearch.hs:(46,0)-(69,39)] *Main> So far so good. This is what I want to see - a listing like this for every (interpreted of course) line of haskell code that runs, all the way to the end. Since this is a very large program, at this point I started pasting this to the terminal - 4 steps at a time... :step :step :step :step This gave me the listing I wanted. But after a certain point, it inevitably fails with a core dump, and what I capture from the screen is garbled up to that point anyway. I'm hoping there's a simpler way to do this. Thanks for taking the time to read this. Ralph

4 3