- Glasgow-haskell-users

Superclass Cycle via Associated Type
by Ryan Trinkle 30 Jul '11

30 Jul '11

The following code doesn't compile, but it seems sensible enough to me. Is this a limitation of GHC or is there something I'm missing? class C (A x) => C x where type A x :: * instance C Int where type A Int = String instance C String where type A String = Int The error I get is: SuperclassCycle.hs:1:1: Cycle in class declarations (via superclasses): SuperclassCycle.hs:(1,1)-(2,15): class C (A x) => C x where { type family A x :: *; } Ryan

8 19

GHC API output files options problem
by Marianna Rapoport 29 Jul '11

29 Jul '11

Hi all, we are working on a Haskell support plugin for IntelliJ IDEA, and need to provide correct compilation of Haskell programs. We compile the latter using GHC API, with options specifying .hi and .o paths. For some reason, unlike a standalone GHC compilation, GHC API ignores the values of the outputFile and outputHi flags. Please find attached a minimal example where "err_test.hs" uses GHC API to compile "src/A.hs". Thus, "test_ghc.sh" and "test_my.sh" should do the same, but the first works correctly while the latter puts "use.o" and "use.hi" to the "src" folder. To launch "test_my.sh", please change the value of lib in "err_test.hs" according to your GHC installation path. Thank you very much in advance! Marianna Rapoport, amaurremi(a)gmail.com Oleg Sobolev, sobolev_ov(a)mail.ru

2 1

integer-simple
by Chris Dornan 28 Jul '11

28 Jul '11

Hi All, I have been trying to get a simple-integer build for GHC without success. It always ends with the build going through fine, but when I try to run ghci I get: GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. ghc: /usr/local/ghc/6.12.3-is/lib/ghc-6.12.3/integer-simple-0.1.0.0/HSinteger-sim ple-0.1.0.0.o: unknown symbol `base_ControlziExceptionziBase_patError_info' Loading package integer-simple ... linking ... ghc: unable to load package `integer-simple' My MO is to . get binary GHC package, install it and put it on the path; . unpack the source distribution and set up build.mk, usually with quicktest, always with INTEGER_LIBRARY = integer-simple; . configure, build and install; . switch the path over from the binary to the new build and run ghci. I have tried this many combinations of build and source trees from ghc-6.12.1 up to 7.0.4 on CentOS/RHEL 5 & 6 with the same result. The above output was taken from a 6.12.3 source tree built with 6.12.2 binaries. Further: . I use 6.12.3 binaries heavily on CentOS 5 with no issue. . On the couple of occasions I have tried a vanilla build (no build.mk), the build breaks down with GMP link errors. Configuring with --with-gmp-includes=/usr/local/include and --with-gmp-libs=/usr/local/lib didn't help. (I did not persist for obvious reasons.) . At least Mik Konecny appears to got this to work for 6.12.3 <http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP> . 'Tis all very odd! Anybody any idea what I am doing wrong? Chris

1 0

Space leak question
by Will Ness 28 Jul '11

28 Jul '11

Hello, in reformulation of a code with no space leak, the leak reappeares. It takes near constant space to get at the n-th elt in the produced list here (http://ideone.com/fiifl) {-# OPTIONS_GHC -O2 -fno-cse #-} primes = 2 : ([3,5..] `minus` foldi (\(x:xs) -> (x:) . union xs) [[x*x, x*x+2*x..] | x<- ys]) where ys = 3 : ([5,7..] `minus` foldi (\(x:xs) -> (x:) . union xs) [[x*x, x*x+2*x..] | x<- ys]) foldi f (x:xs) = f x (foldi f (pairs f xs)) pairs f (x:y:t) = f x y : pairs f t Here it doesn't (http://ideone.com/m744a) {-# OPTIONS_GHC -O2 -fno-cse #-} primes = 2 : g (fix g) where g = (3:) . ([5,7..] `minus`) . foldi (\(x:xs) -> (x:) . union xs) . map (\x-> [x*x, x*x+2*x..]) I expected the 2nd to be equivalent to the 1st. In Hugs (Nov 2002) the reported stats and run times are very similar for the both versions. Is this a GHC thing, or a language thing? Thanks,

2 5

Quoting a quasi-quote
by Yitzchak Gale 27 Jul '11

27 Jul '11

It was pointed out by Ben Millwood on the Cafe that there is an undocumented way to escape the closing oxford bracket of a quasi-quote using a backslash: [s|This quasi-quote contains this, \|], an escaped closing oxford bracket.|] The backslash itself cannot be escaped in this way: [s|Also contains an escaped bracket \\|] |] Thus there is a fairly strong limitation on the contents of a quasi-quote: it can never end in a backslash. This behavior is not mentioned in the GHC docs. Is it a mistake, or is it meant to be a supported feature? This behavior is a bit surprising to me. Since the whole point of a quasi-quoter is to allow the user to define syntax, you would think that the syntax for the quasi-quote itself would be as quiet as possible and stay out of the way. People who need to be able to escape the closing bracket can easily define their own syntax to do so. In any case, if this is indeed a feature, it certainly should be documented. Thanks, Yitz

4 3

Understanding behavior of BlockedIndefinitelyOnMVar exception
by Brandon Simmons 26 Jul '11

26 Jul '11

I'm trying to really understand how the BlockedIndefinitelyOnMVar exception works in concurrent code as I would like to rely on it as a useful runtime signal in a concurrency library I'm working on. Here is some code illustrating a function restoring an abandoned lock in a single-threaded program and works as I would expect: -------- START CODE -------- module Main where import Control.Concurrent import Control.Exception -- This raises the exception only once and the lock is successfully restored: main1 = do lock <- newMVar () lockPrint "good1" lock badLockPrint "bad" lock -- exception is raised and lock is restored here: lockPrint "good2" lock -- no exception raised: lockPrint "good3" lock readMVar lock lockPrint :: String -> MVar () -> IO () lockPrint name v = do e <- try $ takeMVar v :: IO (Either BlockedIndefinitelyOnMVar ()) -- either print exception, or print name: either print (const $ putStrLn name) e `finally` putMVar v () -- perhaps simulates an operation that died before it could return a lock: badLockPrint :: String -> MVar () -> IO () badLockPrint s v = do takeMVar v putStrLn s -- Forgot to return the lock here!: -------- END CODE -------- Now here is a variation of 'main' that forks the operations: -------- START CODE -------- main0 = do lock <- newMVar () forkIO $ lockPrint "good1" lock threadDelay 1000000 forkIO $ badLockPrint "bad" lock -- these both raise blocked indefinitely exception threadDelay 1000000 forkIO $ lockPrint "good2" lock threadDelay 1000000 forkIO $ lockPrint "good3" lock threadDelay 1000000 -------- END CODE -------- What I think I've learned here is that the BlockedIndefinitelyOnMVar exception is raised in all the blocked threads "at once" as it were. That despite the fact that the handler code in 'lockPrint' restores the lock for successive threads. This would also seem to imply that putMVar's in an exception handler don't stop the runtime from raising the BlockedIndefinitelyOnMVar. But that doesn't really seem right. Can anyone comment on the two conclusions above? FWIW, this was an interesting related thread: http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/18667 Thanks, Brandon Simmons http://coder.bsimmons.name

3 6

GHC 7.0.4 on Lion
by Luca Ciciriello 26 Jul '11

26 Jul '11

Hi All. I've installed on my Mac the new MacOS X 10.7 (Lion) with Xcode 4.1 Using ghc 7.0.4 (64-bit) on that system a get the following warnings in the linking phase: Linking hslint ... ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in ___gmpn_modexact_1c_odd from /Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/integer-gmp-0.2.0.3/libHSinteger-gmp-0.2.0.3.a(mode1o.o). To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie Is this something to worrying about? Thanks in advance for any answer. Luca

3 3

Re: Superclass Cycle via Associated Type
by Edward Kmett 21 Jul '11

21 Jul '11

*Simon Peyton-Jones* simonpj at microsoft.com <glasgow-haskell-users%40haskell.org?Subject=Re%3A%20Superclass%20Cycle%20via%20Associated%20Type&In-Reply-To=%3C59543203684B2244980D7E4057D5FBC125661A72%40DB3EX14MBXC308.europe.corp.microsoft.com%3E> ------------------------------ You point is that the (C Int) dictionary has (C String) as a superclass, and > (C String) has (C Int) as a superclass. So the two instances are mutually > recursive, but that's ok. > That is not unreasonable. But it is dangerous. Consider > class C [a] => C a > Then any dictionary for (C a) would contain a dictionary for (C [a]) which > would contain a dictionary for C [[a]], and so on. Haskell is lazy so we > might even be able to build this infinite dictionary, but it *is* infinite. > It's a bit like the "recursive instance" stuff introduced in "Scrap your > boilerplate with class". > After 5 mins thought I can't see a reason why this could not be made to > work. But it'd take work to do. If you have a compelling application maybe > you can open a feature request ticket, describing it, and referring this > thread? > Has anyone else come across this? > Yes. This is actually an active problem for me in my 'algebra' package. We can define additive, additive abelian and multiplicative semigroups: class Additive m where (+) :: m -> m -> m class Additive m => Abelian m class Multiplicative m where (*) :: m -> m -> m then we can define semirings (in the semirings are semigroups with distributive laws sense): class (Additive m, Abelian m, Multiplicative m) => Semiring m then to define monoids, we enforce the fact that every additive monoid is a module over the naturals. class (Semiring r, Additive m) => LeftModule r m where (.*) :: r -> m -> m class LeftModule Natural m => Monoidal m where This makes it an obligation of anyone that provides a Monoidal instance to ensure that they also supply the LeftModule, side-stepping what would be a hugely overlapping instance, and ensuring we can rely on it. But we weren't able to exploit the fact that any Additive semigroup forms a module over N+, due to the cycle. Moreover, we also weren't able to encode that every semiring is a module over itself. If we could have superclass cycles, we could restate this all as class LeftModule Whole m => Additive m where (+) :: m -> m -> m class Additive m => Abelian m class (Semiring r, Additive m) => LeftModule r m where (.*) :: r -> m -> m class Multiplicative m where (*) :: m -> m -> m class LeftModule Natural m => Monoidal m where zero :: m class (Abelian m, Multiplicative m, LeftModule m m) => Semiring m class (LeftModule Integer m, Monoidal m) => Group m where recip :: m -> m class Multiplicative m => Unital m where one :: m class (Monoidal r, Unital r, Semiring r) => Rig r where fromNatural :: Natural -> r fromNatural n = n .* one class (Rig r, Group r) => Ring r where fromInteger :: Integer -> r fromInteger n = n .* one ... There are a number of typeclass cycles in there, but I can safely instantiate the whole mess without any overlapping instances and I already have to ball all of these classes up in the same 'Internals' module to avoid orphans instances anyways. Using the usual dodge of a newtype to provide Self module over any given semiring is particularly unsatisfying because the Natural and Integer multiplication become horrific, and I wind up having to multiply the code below this point in the hierarchy to deal with the 'self algebra' cases. =/ I've also run into the problem about once or twice a year when encoding other concepts that are usually more categorical in nature. I would love to be able to do this. -Edward Kmett

1 0

HEAD doesn't not build on OS X
by Johan Tibell 20 Jul '11

20 Jul '11

While trying to build head (from a maintainer-clean tree) I get the following error: echo "compiler_stage1_depfile_haskell_EXISTS = YES" >> compiler/stage1/build/.depend-v.haskell.tmp for dir in compiler/stage1/build/./ compiler/stage1/build/Llvm/ compiler/stage1/build/LlvmCodeGen/ compiler/stage1/build/PPC/ compiler/stage1/build/RegAlloc/ compiler/stage1/build/RegAlloc/Graph/ compiler/stage1/build/RegAlloc/Linear/ compiler/stage1/build/RegAlloc/Linear/PPC/ compiler/stage1/build/RegAlloc/Linear/SPARC/ compiler/stage1/build/RegAlloc/Linear/X86/ compiler/stage1/build/SPARC/ compiler/stage1/build/SPARC/CodeGen/ compiler/stage1/build/Vectorise/ compiler/stage1/build/Vectorise/Builtins/ compiler/stage1/build/Vectorise/Monad/ compiler/stage1/build/Vectorise/Type/ compiler/stage1/build/Vectorise/Utils/ compiler/stage1/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' compiler/stage1/build/.depend-v.haskell.tmp > compiler/stage1/build/.depend-v.haskell "/usr/sbin/dtrace" -Iincludes -Irts -Ilibffi/build/include -C -x cpppath=/usr/bin/gcc -h -o rts/dist/build/RtsProbes.h -s rts/RtsProbes.d . includes/HsFFI.h .. includes/ghcconfig.h ... includes/ghcautoconf.h ... includes/ghcplatform.h .. includes/stg/Types.h .. /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdint.h .. /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/float.h . includes/rts/EventLogFormat.h dtrace: failed to compile script rts/RtsProbes.d: line 71: parameter is already declared in probe input prototype: StgWord, parameter #6 make[1]: *** [rts/dist/build/RtsProbes.h] Error 1 make: *** [all] Error 2

2 4

memory statistics via an API ?
by Tim Docker 20 Jul '11

20 Jul '11

The "+RTS -s" runtime arguments give some useful details the memory usage of a program on exit. eg: 102,536 bytes allocated in the heap 2,620 bytes copied during GC 36,980 bytes maximum residency (1 sample(s)) 28,556 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Is there any means of obtaining this information at runtime, via some API? It would be useful for monitoring a long running server process. Tim

2 1