- Glasgow-haskell-users

memory ordering
by John Lato 01 Jan '14

01 Jan '14

Hello, I'm working on a lock-free algorithm that's meant to be used in a concurrent setting, and I've run into a possible issue. The crux of the matter is that a particular function needs to perform the following: > x <- MVector.read vec ix > position <- readIORef posRef and the algorithm is only safe if these two reads are not reordered (both the vector and IORef are written to by other threads). My concern is, according to standard Haskell semantics this should be safe, as IO sequencing should guarantee that the reads happen in-order. Of course this also relies upon the architecture's memory model, but x86 also guarantees that reads happen in order. However doubts remain; I do not have confidence that the code generator will handle this properly. In particular, LLVM may freely re-order loads of NotAtomic and Unordered values. The one hope I have is that ghc will preserve IO semantics through the entire pipeline. This seems like it would be necessary for proper handling of exceptions, for example. So, can anyone tell me if my worries are unfounded, or if there's any way to ensure the behavior I want? I could change the readIORef to an atomicModifyIORef, which should issue an mfence, but that seems a bit heavy-handed as just a read fence would be sufficient (although even that seems more than necessary). Thanks, John L.

4 10

Decomposition of given equalities
by Gábor Lehel 31 Dec '13

31 Dec '13

Hello, The upcoming GHC 7.8 recently gave me this error: Could not deduce (i ~ i1) from the context (f1 i ~ f i1) Which is strange to me: shouldn't (f1 i ~ f i1) exactly imply (f1 ~ f, i ~ i1)? (Or with nicer variable names: (f a ~ g b) => (f ~ g, a ~ b)?) When I inquired about this in #haskell on IRC, a person going by the name xnyhps had this to say: > I've also noticed that, given type equality constraints are never decomposed. I'm quite curious why. and later: > It's especially weird because a given f a ~ g b can not be used to solve a wanted f a ~ g b, because the wanted constraint is decomposed before it can interact with the given constraint. I'm not quite so well versed in the workings of GHC's type checker as she or he is, but I don't understand why it's this way either. Is this a relic of https://ghc.haskell.org/trac/ghc/ticket/5591 and https://ghc.haskell.org/trac/ghc/ticket/7205? Is there a principled reason this shouldn't be true? Is it an intentional limitation of the constraint solver? Or is it just a bug? Thanks in advance, Gábor P.S. I got the error on this line: https://github.com/glaebhoerl/type-eq/blob/master/Type/Eq.hs#L181, possibly after having added kind annotations to `InnerEq` (which also gets a less general kind inferred than the one I expect). If it's important I can try to create a reduced test case.

3 9

Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types
by Dr. ERDI Gergo 25 Dec '13

25 Dec '13

Hi, As part of my work to add pattern synonyms to GHC (https://ghc.haskell.org/trac/ghc/ticket/5144) I initially planned to postpone implementing type signatures (https://ghc.haskell.org/trac/ghc/ticket/8584) However, since adding the feature in the first place requires Haddock support, some syntax will be needed for pattern synonym type signatures so that at least there's something to generate into the docs. The basic problem with pattern synonyms in this regard is that their type is fully described by the following five pieces of information: 1, Universially bound type variables 2, Existentially bound type variables 3, The (tau) type itself 4, Typeclass context required by the pattern synonym 5, Typeclass context provided by the pattern synonym To give you some parallels, functions are described by (1), (3) and (4), e.g. given the following definition: f = map fromIntegral (1) is {a, b} (3) is [a] -> [b] (4) is (Integral a, Num b) Data constructors are described by (1), (2), (3) and (5), e.g. given data T a where MkT :: (Num a, Eq b) => a -> (b, b) -> T a the type of `MkT` is described by (1) Universially bound type variables {a} (2) Existentially bound type variables {b} (3) Tau type a -> (b, b) -> T a (5) Typeclass context provided is (Num a, Eq b) Note that when using `MkT` in an expression, its type is simpler than that, since it simply becomes forall a b. (Num a, Eq b) => a -> (b, b) -> T a which has exactly the same shape as the previous example which had (1), (3) and (4) specified. However, the context has different semantics (and the distinction between (1) and (2) becomes important) when pattern matching on `MkT`. For pattern synonyms, all five axes are present and orthogonal, and all five is something that a user should care about. For example, given the following code: {-# LANGUAGE PatternSynonyms, GADTs, ViewPatterns #-} data T a where MkT :: (Num a, Eq b) => a -> b -> T a f :: (Show a) => a -> Bool f = ... pattern P x <- MkT (f -> True) x to fully describe the type of pattern synonym P, we have: (1) Universially quantified type variables {a} (2) Existentially quantified type variables {b} (3) Tau type b -> T a (4) Required context (Show a) (5) Provided context (Num a, Eq b) So, what I'm looking for, is ideas on what syntax to use to represent these five pieces of information. Note that (1) and (2) can be made implicit, just like for constructor types, simply by noting that type variables that don't occur in the result type are existentially bound. So the tricky part is maintaining the distinction between (4) and (5). The current implementation displays the following if you ask for `:info T`: > :info P pattern P :: b -> T t requires (Show t) provides (Num t, Eq b) but I don't think we would want to use that for syntax that is actually enterred by the user into type signatures (if nothing else, then simply because why would we want to use two extra keywords 'requires' and 'provides'). The one idea I've had so far is to separate (4), (3) and (5) with two double arrows: pattern P :: (Show t) => b -> T t => (Num t, Eq b) As an added extra problem, there are also unidirectional and bidirectional pattern synonyms: unidirectional ones are usable only as patterns, whereas bidirectional ones can also be used as expressions. For example: pattern Single x = [x] pattern Second x <- (_:x:_) in this example, `Single` is bidirectional and `Second` is unidirectional. As you can see, this is indicated by syntax in the definition (`=` vs `<-`). However, I'd like to show this in the type as well, since you'd need to be able to see if you can use a given pattern synonym as a "constructor", not just a "destructor", by just looking at its Haddock-generated docs. What do you think? Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' Either the chocolate in my pocket has melted, or this is something altogether more sinister.

5 12

ghc src snapshots
by Jens Petersen 24 Dec '13

24 Dec '13

Are recent source tarball snapshots available somewhere? (I mean more recent than http://darcs.haskell.org/ghcBuilder/uploads/ :) Anyway since I haven't seen any recently, I finally rolled one today and uploaded ghc-7.7.20131005-src.tar.bz2 (11MB) to: http://petersen.fedorapeople.org/ghc/ It seems to build ok for me. :) (I didn't go to the trouble of generating a testsuite tarball too.) Thanks, Jens

1 2

Fwd: Decomposition of given equalities
by Thijs Alkemade 19 Dec '13

19 Dec '13

[Resending to the list, I used the wrong address. Sorry for the duplicate copies.] On 19 dec. 2013, at 05:30, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > I'd say GHC has it right in this case. > > (f a ~ g b) exactly implies (f ~ g) and (a ~ b) if and only if the kinds match up. If, say, (f :: k1 -> *), (g :: k2 -> *), (a :: k1), and (b :: k2), then (f ~ g) and (a ~ b) are ill-kinded. In Gabor's initial problem, we have (with all type, kind, and coercion variables made explicit) But even when it can know the kinds match up it doesn’t decompose it. For example: — {-# LANGUAGE TypeFamilies #-} foo :: (f a ~ g b) => f a -> g b foo = id — Ends up with 2 errors (7.6.3): Could not deduce (a ~ b) from the context (f a ~ g b) Could not deduce (f ~ g) from the context (f a ~ g b) So the wanted constraint f a ~ g b was decomposed, meaning the kind of a and b, and f and g were already found to be equal. Even with an explicit kind signature on every variable it doesn't work: foo :: (f a ~ g b) => (f :: * -> *) (a :: *) -> (g :: * -> *) (b :: *) I can’t think of an example where f a ~ g b holds, but the kinds of a and b are different. Thijs (“xnyhps”)

1 0

Better GHC builds for Windows users
by Austin Seipp 09 Dec '13

09 Dec '13

Hello all, After fiddling around this weekend I've written a quick, comprehensive guide to a Better Build Environment for windows users. It pretty much "Just works" and I think should make it easy to get started with new machines: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 Many thanks to Kyra for pointing this out to us on the GHC developer list. It is a much nicer to use mingw/msys environment with a lot of bugs fixed, and it's easy to install. Following the instructions should mostly be copy-paste. In particular, this resolves some weird issues with `validate` and traditional `make`, including a horrible deadlocking bug with make (and also 'tee', it seems.) So windows users can build in parallel again and everything works as expected. It also gives a simple and complete guide to build for x86_64 users (we didn't really mention it previously.) Please shout if you have problems. I've tested this with both an x86 and x86_64 build. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

love for hpc?
by Evan Laforge 13 Nov '13

13 Nov '13

Is anyone out there using HPC? It seems like it was gotten into a more or less working if not ideal state, and then abandoned. Things I've noticed lately: The GHC runtime just quits on the spot if there's already a tix file. This bit me when I was parallelizing tests. It's also completely unsafe when run concurrently, mostly it just overwrites the file, sometimes it quits. Sure to cause headaches for someone trying to parallelize tests. You can't change the name of the output tix file, so I worked around by hardlinking the binary to a bunch of new ones, and then doing 'hpc sum' on the results. The hpc command is super slow. It might have to do with it doing its parsing with Prelude's 'read', and it certainly doesn't help the error msgs. And the whole thing is generally minimally documented. I can already predict the answer will be "yes, HPC could use some love, roll up your sleeves and welcome!" It does look like it could be improved a lot with just a bit of effort, but that would be a yak too far for me, at the moment. I'm presently just curious if anyone else out there is using it, and if they feel like it could do with a bit of polishing.

6 6

Adding new library dependencies to GHC
by Alex Ford 13 Nov '13

13 Nov '13

Hi, I've made some changes to the LLVM backend of GHC to make it use llvm-general to output bitcode rather than pretty printing human readable LLVM assembly. However, I've been having trouble linking the required libraries (llvm-general and its transitive dependencies). The steps I've taken so far are to put the required libraries in the build tree under libraries, and added them to the packages file, to PACKAGES_STAGE0 and PACKAGES_STAGE1 in ghc.mk, and to the build depends section in compiler/ ghc.cabal.in. The build fails in phase 1 when trying to link utf8-string (a dependency of llvm-general) during the build of llvm-general, with: Loading package utf8-string-0.3.7 ... <command line>: can't load .so/.DLL for: libHSutf8-string-0.3.7.so (libHSutf8-string-0.3.7.so: cannot open shared object file: No such file or directory) The problem seems to be that with pre-existing library dependencies, the system-wide libraries at /usr/lib/ghc-7.6.3/<libname>/ are pulled in, whereas with the new dependencies, versions within the build tree (e.g. at libraries/utf8-string/dist-install/build/) are tried instead, despite these new libraries being installed globally within the same parent directory and being listed by ghc-pkg (no errors upon ghc-pkg check either). For example, in compiler/stage1/package-data.mk, compiler_stage1_DEP_LIB_DIRS_SEARCHPATH specifies /usr/lib/ghc-7.6.3/bytestring-0.10.0.2, and bytestring links successfully, but for utf8-string specifies <ghc-base-dir>/libraries/utf8-string/dist-boot/build. I've read through the documentation on libraries for GHC but can't figure out how to make this work. Could anyone suggest how I could go about fixing this? As a slightly related question, llvm-general depends on template-haskell. Will this cause problems when building GHC normally, since the stage 1 compiler does not support TH? If so is there any way to compile stage 2 directly using the stage 0 compiler? Many thanks, Alex

2 1

Giving function a larger arity
by Akio Takano 13 Nov '13

13 Nov '13

Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help. Specifically, it involves a library that defines a newtype whose representation is a function. Attached Lib.hs is an example of such a library. It defines a newtype (Builder), and functions (fromInt, mappend) that deal with it. In user code I want to write a (often-recursive) function that produces a value of the newtype (the 'upto' function in arity.hs is an example). The problem is that I know that the resulting value will be used only once, and I'd like GHC to take advantage of it. In other words, I want the 'upto' function to get compiled into something that takes 4 arguments (Int#, Int#, Addr# and State#), rather than a binary function that returns a lambda. I understand that GHC does not do this by default for a good reason. It avoids potentially calling 'slightlyExpensive' more than once. However I need some way to get the larger arity, because the performance difference can be rather large (for example, this problem can add a lot of boxing to an otherwise allocation-free loop). One of my attempts was to have the library expose a function with which the user can tell GHC that re-computation is okay. Lib.rebuild is such a function, and the 'upto_rebuild' function demonstrates how to use it. Unfortunately this approach only worked when the full-laziness optimization was explicitly disabled. This problem happened many times to me. In particular Reader and State monads often triggered it. I'm using GHC 7.6.3. Any advice? Thank you, Takano Akio

5 8

blocking parallel program
by Facundo Domínguez 11 Nov '13

11 Nov '13

Hello, Below is a program that seems to block indefinitely with ghc in a multicore machine. This program has a loop that does not produce allocations, and I understand that this may grab one of the cores. The question is, why can't the other cores take the blocked thread? The program was compiled with: $ ghc --make -O -threaded test.hs and it is run with: $ ./test Program text follows. Thanks, Facundo -------- import Control.Concurrent import Control.Monad import System.Environment main :: IO () main = do y <- getArgs mv0 <- newEmptyMVar mv1 <- newEmptyMVar forkIO $ do takeMVar mv0 putMVar mv1 () loop (y == ["yield"]) putMVar mv0 () takeMVar mv1 loop :: Bool -> IO () loop cooperative = go where go = when cooperative yield >> go

2 5