- Glasgow-haskell-users

ghc 7.6.1 panic, http://hackage.haskell.org/trac/ghc/ticket/5252 not dead yet
by Evan Laforge 13 Sep '12

13 Sep '12

So I have something that looks similar to http://hackage.haskell.org/trac/ghc/ticket/5252, namely, given these two modules: % cat Midi.hs {-# OPTIONS_GHC -funbox-strict-fields #-} module Midi ( WriteMessage(..) , WriteDevice -- TODO due ghc bug: http://hackage.haskell.org/trac/ghc/ticket/5252 -- , WriteDevice(WriteDevice) ) where import qualified Data.ByteString as ByteString data WriteMessage = WriteMessage !WriteDevice newtype WriteDevice = WriteDevice ByteString.ByteString % cat CoreMidi.hs module CoreMidi where import qualified Midi write_message :: Midi.WriteMessage -> IO Bool write_message (Midi.WriteMessage _) = return True % ghc -c Midi.hs % ghc -c CoreMidi.hs ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-apple-darwin): reboxProduct: not a product main:Midi.WriteDevice{tc r2M} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Oddly, if I put {-# UNPACK #-} on the strict WriteDevice and remove -funbox-strict-fields, I don't get a crash anymore. Also, it has to be ByteString inside, I guess it has to do with the optimization ByteString applies. Shall I append to the old ticket, or create a new one?

1 0

recent changes to hsc2hs break wrapping c++
by Evan Laforge 09 Sep '12

09 Sep '12

Recently a change was made to hsc2hs to fix this ticket: http://hackage.haskell.org/trac/ghc/ticket/2897 Unfortunately, the result is I (apparently) can't use it now. Here's how that happens: The change was to remove the dependency on HsFFI.h. However, the solution is to create a little wrapper .c file that includes wrappers around various stdio functions like fputs(). This relies on C allowing implicit casts from void* to e.g. FILE*, and is also happy to let you use undeclared functions. g++ rejects that code. And since I am calling into C++ (via a 'extern "C" { ... }' wrapper) I wind up including C++ headers that contain the structs I want hsc2hs to calculate offsets for. Of course one solution is to use C as hsc2hs expects, but it would be awkward to split my (largish) c++ program's headers into C compatible and C++ only. So meanwhile I've reverted back to an older version of hsc2hs that includes HsFFI.h. Working with c++ headers was maybe not in the original design for hsc2hs, but it's a very useful feature nonetheless. WRT HsFFI.h and the ticket, I added -I(ghc --print-libdir)/include to my hsc2hs rule a long time ago, and it wasn't very hard to do, though I admit it would have been easier had there been documentation about what to do, or a mandatory flag for the HsFFI.h path. It looks like Duncan suggested that already. Or perhaps there's a better way to wrap C++?

3 6

Re: [Haskell] ANNOUNCE: GHC version 7.6.1
by Dennis Felsing 07 Sep '12

07 Sep '12

On 2012-09-07T09:00+1000, Ivan Lazar Miljenovic wrote: > > * It is now possible to defer type errors until runtime using the > > -fdefer-type-errors flag. > > Is this flag reversible in ghci, so I can :set it to check what's > going wrong with some code and then :unset it again? As you can see on http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/flag-reference.html -fdefer-type-errors is dynamic, so you can reverse it using -fno-defer-type-errors.

1 0

Re: Holes in GHC
by Thijs Alkemade 05 Sep '12

05 Sep '12

Hi Simon and others, Yes, an update on our holes in GHC project was very due. What I've been working on: - The command line flag -XHoles and as a language pragma {-# LANGUAGE Holes #-} now work - Holes print a warning message with: - The origin of their type variables - Their local environment - Most of the code has been cleaned up to prepare it for submission as a patch. As an example of the message, consider the module: --- {-# LANGUAGE Holes #-} test x = foldr _ x _ --- This prints: --- [1 of 1] Compiling Main ( test2.hs, interpreted ) test2.hs:3:16: Warning: Found hole `_' with type a0 -> b -> b Where: `b' is a rigid type variable bound by the inferred type of test :: b -> b at test2.hs:3:1 `a0' is a free type variable In scope: x :: b test2.hs:3:20: Warning: Found hole `_' with type [a0] Where: `a0' is a free type variable In scope: x :: b Ok, modules loaded: Main --- The 3 currently remaining issues: - Free type variables are not tidied consistently. For every one of these hole warnings, the same TidyEnv is reused, without taking the updates from the other holes into account. I'm pretty sure I know where this happens and how I could fix it. - What I thought would be the local environment doesn't actually seem to be it. The holes store in their origin the result of `getLclTypeEnv' at their location, but as the Note [Bindings with closed types] says, the TopLevelFlag of these don't actually differentiate the top level from the non-top level bindings. I think it would be more helpful to only show the non-top level bindings at the hole's location, any hints about how to obtain just these would be appreciated. - The holes do not have very accurate source location information, like some other errors have. The hole has its origin, ("test2.hs:3:16"), but somehow not something like: "In the expression: folder _ x _, In an equation for `test': test x = foldr _ x _". Help with how that is supposed to work would also be appreciated. I'm attaching a patch of all my changes compared to HEAD as of about a week ago. All my work can also still be found on https://github.com/xnyhps/ghc. Best regards, Thijs Alkemade

4 4

Constraint error related to type family and higher-rank type
by Tsuyoshi Ito 05 Sep '12

05 Sep '12

Hello, Can anyone please explain why the following code is rejected by GHC (7.4.1)? The same code is also available at https://gist.github.com/3606849. ----- {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Test1 where class C a b | b -> a data A = A data X = X data Y = Y type family TF b f :: (forall b. (C a b, TF b ~ Y) => b) -> X f _ = undefined u :: (C A b, TF b ~ Y) => b u = undefined v :: X v = f u -- This line causes an error (see below) ----- (1) GHC rejects this code with the following error message. Test1.hs:24:7: Could not deduce (C A b) arising from a use of `u' from the context (C a_c b, TF b ~ Y) bound by a type expected by the context: (C a_c b, TF b ~ Y) => b at Test1.hs:24:5-7 Possible fix: add (C A b) to the context of a type expected by the context: (C a_c b, TF b ~ Y) => b or add an instance declaration for (C A b) In the first argument of `f', namely `u' In the expression: f u In an equation for `v': v = f u (2) If I remove “TF b ~ Y” from the type of the argument of f and the type of u, then the code compiles. This suggests that the error message in (1) might not be the accurate description of the problem. (3) If I write “(f :: (forall b. (C A b, TF b ~ Y) => b) -> X)” instead of just “f” in the definition of v, then GHC reports a different error: Test1.hs:24:6: Cannot deal with a type function under a forall type: forall b. (C A b, TF b ~ Y) => b In the expression: f :: (forall b. (C A b, TF b ~ Y) => b) -> X In the expression: (f :: (forall b. (C A b, TF b ~ Y) => b) -> X) u In an equation for `v': v = (f :: (forall b. (C A b, TF b ~ Y) => b) -> X) u Item (3) might be related to a fixed Ticket #4310: http://hackage.haskell.org/trac/ghc/ticket/4310#comment:2 Best regards, Tsuyoshi

2 2

RFC: Adding support for an API-"since"-version-attribute to Haddock?
by Herbert Valerio Riedel 05 Sep '12

05 Sep '12

Hello Haskellers, I've been wondering whether it might be useful to add a feature to Haddock similar to what can be found in other API documentation systems, specifically an optional parseable "since"-attribute, declaring the last package version when the associated definition/symbol was introduced or its semantics modified. Beyond giving a uniform/standard representation for this kind of information (e.g. if Haddock would render this information in a distinctive style suitable to give a visual hint for locating this information easily), this information could be used to generate an automated changelog entry (at least for the current package version), listing all definitions added or modified with the current version. Another application I could thinkg of would be to find the lowest version of a package supporting the currently used API from it (given the currently known-to-work package-version and a list of currently used symbols from that package). Would such an enhancement to Haddock be worthwhile or is it a bad idea? Has such a proposal come up in the past already? Are there alternative approaches to consider?

8 9

Small Int and Char closures in GHCi
by Joachim Breitner 31 Aug '12

31 Aug '12

Hi, I am preparing a talk about the details of how data and programs look in memory in Haskell (well, GHC). When explaining the memory consumption of a large String, I wanted to show the effect of short-int-replacement that happens in http://hackage.haskell.org/trac/ghc/browser/rts/sm/Evac.c#L550 I use my ghc-heap-view-package to observe the heap. This programs shows the effect: import GHC.HeapView import System.Mem main = do let hallo = "hallo" mapM_ (\x -> putStrLn $ show x ++ ": " ++ show (asBox x)) hallo performGC mapM_ (\x -> putStrLn $ show x ++ ": " ++ show (asBox x)) hallo gives, as expected: $ ./SmallChar 'h': 0x00007f2811e042a8/1 'a': 0x00007f2811e08128/1 'l': 0x00007f2811e09ef0/1 'l': 0x00007f2811e0bcd8/1 'o': 0x00007f2811e0db10/1 'h': 0x00000000006d9bd0/1 'a': 0x00000000006d9b60/1 'l': 0x00000000006d9c10/1 'l': 0x00000000006d9c10/1 'o': 0x00000000006d9c40/1 but in GHCi, it does not work: $ runhaskell SmallChar.hs 'h': 0x00007f5334623d58/1 'a': 0x00007f5334626208/1 'l': 0x00007f5334627fc0/1 'l': 0x00007f5334629dc0/1 'o': 0x00007f533462bba8/1 'h': 0x00007f533381a1c8/1 'a': 0x00007f5333672e30/1 'l': 0x00007f533381a408/1 'l': 0x00007f533381a6b8/1 'o': 0x00007f533389c5d0/1 Note that the GC does evacuate the closures, as the pointers change. Why are these not replaced by the static ones here? Thanks, Joachim -- Joachim "nomeata" Breitner mail(a)joachim-breitner.de | nomeata(a)debian.org | GPG: 0x4743206C xmpp: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/

2 2

ANNOUNCE: GHC 7.6.1 Release Candidate 1
by Ian Lynagh 31 Aug '12

31 Aug '12

We are pleased to announce the first release candidate for GHC 7.6.1: http://www.haskell.org/ghc/dist/7.6.1-rc1/ This includes the source tarball, installers for 32bit and 64bit Windows, and bindists for amd64/Linux, i386/Linux, amd64/OSX and i386/OSX. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

10 11

Question about type lits and optimization in ghc
by Iavor Diatchki 30 Aug '12

30 Aug '12

Hello, On Thu, Aug 23, 2012 at 2:03 AM, Simon Peyton-Jones <simonpj(a)microsoft.com>wrote: > I’m hazy about **** > > **· **the definitions of sing and fromSing > The family of singleton types, Sing, is quite general. However, when its parameter is of kind `Nat`, then it is simply a newtype for `Integer`: data family Sing (s :: a) newtype instance Sing (s :: Nat) = SingN Integer To access the `Integer` of a `Sing n` value we use the class `SingE`. Again, this is just so that we can support arbitrary singletons, but when the argument is of kind `Nat` we simply access the newtype's `Integer`: instance SingE (n :: Nat) Integer where fromSing (SingN x) = x Finally, `Sing n` values are introduced with the following class: class SingI n where sing :: Sing n The instances of this class when `n` is of kind `Nat` are built into GHC: when GHC needs to solve constraint like `SingI 5`, the solver provides a special piece of evidence, which is essentually 5 (actually, it is `EvLit (EvNum 5)`). When the evidence is desugered into Core, this is replaced with just the integer 5. (Aside: this is not strictly speaking correct---it should be replace with 5 coerced into `Sing 5`, which should then be coerced into the dictionary for `SingI 5`. These all have the same representation so things work for the time being, but this is certainly on my TODO list to correct). · **the transformations that are supposed to simplify (fromSing > (sing :: Sing c)) to c > So, now consider an expression like `fromSing (sing :: Sing 5)`. With explicit dictionaries it becomes: `fromSing d1 (sing d2)`. As we just discussed, `d2` is essentially 5, while `d1` will be the function in the `fromSing` instance above, which is really just a coercion because it accesses the field of a newtype. But note that so are `sing` and `fromSing` because they are methods of classes with just a single method! So this whole expressions really is a whole lot of coercions around 5, which is why I'd expect this kind of pattern to always be simplified. > **** > > **· **the details of the two examples you describe and what isn’t > happening that you expect to happen**** > > ** > Now for the example where I was expecting an optimization to happen but it did not. Consider the following program, with the two different definitions for `x`: main :: IO () main = print (fromInteger x :: Int) where x = 5 :: Integer -- x = fromSing (sing :: Sing 5) With the first definition, where `x` is simply 5, the interesting part of the Core looks like this: main2 :: String main2 = $wshowSignedInt 0 5 ([] @ Char) What's nice about this is that GHC has noticed that it does not need to make the intermediate `Integer` value, and replaced it with and `Int`. If we use the second definition for `x`, then we get a slightly less efficint version: main3 :: Type.Integer main3 = __integer 5 main2 :: String main2 = case integerToInt main3 of wild_ap2 { __DEFAULT -> $wshowSignedInt 0 wild_ap2 ([] @ Char) } Note that, for some reason, the call to `integerToInt` is not eliminated. I am not quite sure why that is. -Iavor > ** > > Can you give more specifics? > > S**** > > ** ** > > *From:* Iavor Diatchki [mailto:iavor.diatchki@gmail.com] > *Sent:* 23 August 2012 07:21 > *To:* Carter Schonwald > *Cc:* Simon Peyton-Jones > *Subject:* Re: question about type lits and optimization in ghc**** > > ** ** > > Hello,**** > > ** ** > > On Wed, Aug 22, 2012 at 10:15 PM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote:**** > > I'm asking about whether or no the compile time machinery of ghc will be > statically replacing "fromSing (sing :: Sing c)" with "c" when "c" is a > specific number at compile time. **** > > ** ** > > Yes, the intention is that this should be simplified into the > corresponding the value `c` of type `Integer`. I just run a small test. > This program:**** > > ** ** > > main :: IO ()**** > > main = print (fromSing (sing :: Sing 5))**** > > ** ** > > results in core which looks like this:**** > > ** ** > > main3 :: Integer**** > > main3 = __integer 5**** > > ** ** > > main2 :: [Char]**** > > main2 = $w$cshowsPrec 0 main3 []**** > > ** ** > > main1 :: State# RealWorld -> (# State# RealWorld, () #)**** > > main1 = \ eta_B1 -> hPutStr2 stdout main2 True eta_B1**** > > ** ** > > main4 :: State# RealWorld -> (# State# RealWorld, () #)**** > > main4 = \ eta_Xa -> runMainIO1 main1 eta_Xa**** > > ** ** > > This is pretty much the same code that one gets for `print 5`. I also > tried a variation:**** > > ** ** > > print (fromInteger (fromSing (sing :: Sing 5)) :: Int)**** > > ** ** > > While this also gets simplified to the integer 5, it does not work quite > as well as `print (fromIntegr 5 :: Int)`, which goes directly to an `Int` > without going through an `Integer` first. I suspect that the reason for > this is that there is some RULE which is not firing, but I'll have to look > into what's going on in a bit more detail. Perhaps Simon has an idea?**** > > ** ** > > -Iavor**** > > ** ** > > ** ** > > On Thu, Aug 23, 2012 at 1:11 AM, Iavor Diatchki < > iavor.diatchki(a)gmail.com> wrote:**** > > Hello,**** > > ** ** > > There are no custom optimizations specifically for type-literals but GHC's > usual optimizations should work well in examples like yours because using a > singleton value is essentially the same as writing the corresponding value > level literal.**** > > So, for example, the indexing function might look something like this:**** > > ** ** > > index :: forall r c a. SingI c => Matrix r c a -> Integer -> Integer > -> a**** > > index (Matrix arr) row col = arr ! (row * fromSing (sing :: Sing c) + > col)**** > > ** ** > > Here, the `SingI` constraint says that we are going to be using the > singleton value associated with type `c`. The function `fromSing` converts > this singleton value into an ordinary `Integer`.**** > > ** ** > > Now, if we use `index` in a context where the dimensions of the matrix are > known, then GHC will resolve the constraint and pass the corresponding > value to `index`. For example, assuming that `index` gets inlined,**** > > the expression:**** > > ** ** > > index (Matrix m :: Matrix 3 4 Int) 1 2**** > > ** ** > > should end up looking something like this:**** > > ** ** > > m ! (1 * 4 + 2)**** > > **** > > which should be simplified further to:**** > > ** ** > > m ! 6 **** > > ** ** > > Does that answer your question? Please ask away if something does not > make sense, or if you notice that things do not work as expected.**** > > ** ** > > Cheers,**** > > -Iavor**** > > ** ** > > On Tue, Aug 21, 2012 at 11:14 AM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote:**** > > Hey GHC folks!**** > > **** > > In the case where type lits (naturals specifically) are statically known > (rather than abstract), is it possible to have a sort of static copy > propagation / Singelton simplification happen at compile time? (Ie can GHC > do such things with type lits as presently implemented?)**** > > ** ** > > a simple example might be that a statically sized matrix, and being able > to specialize the stride and bounds checking at compile time (pseudo code > example follows)**** > > ** ** > > data Mat (row::Nat) (col::Nat) elem = ... some vector representation**** > > ** ** > > ** ** > > index:: (Mat r c el) -> (Word,Word) -> el**** > > index mt ix = ... some stride based indexing calculation that gets at the > "r" and "c" numbers via the singletons to translate the ix tuple into the > index into the underlying vector**** > > representation**** > > {-# perhaps an inline pragma? #-}**** > > ** ** > > indexSpec3x3:: (Mat 3 3 el) -> (Word, Word) -> el**** > > indexSpec3x3 smat ix = smat `index` ix**** > > ** ** > > under what circumstances can i get something like the body of indexSpec3x3 > to use the static type level natural number machinery to partially > specialize the computation?**** > > Does my question even make sense as phrased?**** > > ** ** > > thanks!**** > > ** ** > > -Carter**** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users**** > > ** ** > > ** ** > > ** ** >

1 0

Comparing StableNames of different type
by Emil Axelsson 28 Aug '12

28 Aug '12

Hi! Are there any dangers in comparing two StableNames of different type? stEq :: StableName a -> StableName b -> Bool stEq a b = a == (unsafeCoerce b) I could guard the coercion by first comparing the type representations, but that would give me a `Typeable` constraint that would spread throughout the code. -- / Emil

5 11