ghc

Is there options, except -O0 , that can speed up compilation time? It's not matter if resulting programs will be not optimised. Actually I want to just type-check large haskell package often and fast. Flag -fno-code dramatically speeds up compilation but it's not possible to use it because TemplateHaskell is used by this program. Looks like a task for hdevtools ! Hdevtools is used to as a backend for vim-plugin of the same name and it provides speedy syntax and type checking, directly from the editor. It is about as fast as ghci when reloading modules. I assume that it can be used from the

Converting non-negative Integer to its list of digits is commonly done like this: import Data.Char digits :: Integer -> [Int] digits = (map digitToInt) . show I was trying to find a more direct way to perform the task, without involving a string conversion, but I'm unable to come up with something faster. Things I've been trying so far: The baseline: digits :: Int -> [Int] digits = (map digitToInt) . show Got this one from another question on StackOverflow: digits2 :: Int -> [Int] digits2 = map (`mod` 10) . reverse . takeWhile (> 0) . iterate (`div` 10) Trying to roll my own: digits3 :: Int ->

The output of stack ghc -- --version is The Glorious Glasgow Haskell Compilation System, version 7.10.3 I want to upgrade to GHC 8. How can I tell Stack to upgrade GHC? mac10688 User dysfun from the IRC answered my question so I will post it here for posterity. To update GHC that's used to compile a project, go to the project's stack.yaml file. In there is the resolver field. Update that accordingly. Some examples: resolver: ghc-8.0.2 resolver: lts-9.0 resolver: nightly-2015-09-21 For my case, I learned from this webpage that resolver lts-9.0 uses GHC 8.0.2. Here's more on Stack's resolvers.

Full laziness has been repeatedly demonstrated to cause space leaks . Why is full laziness on from -O onwards? I find myself unconvinced by the reasoning in SPJ's The Implementation of Functional Programming Languages . The claim is that in f = \y -> y + sqrt 4 sqrt 4 is unnecessarily repeated each time f is entered so we should float it outside the lambda. I agree in the small, but since we've seen what problems this transformation causes in the large I don't believe it is worth it. It seems to me that the benefits of this transformation are obtainable unilaterally** with only local code

Can I disable the non-exhaustive pattern matches warning only for lambdas? I like the warning in general, but not for actual lambda literals like this: map (\(x:xs)->...) ls I think this code makes it pretty clear that I expect all the values of ls to always have at least one element, and there is no neat way to handle the error case in the lambda. (I guess I could move the pattern match into a case statement, but that would just be ugly.) Yes, but only in GHC 7.2 onwards; pass -fno-warn-incomplete-uni-patterns (e.g. in your Cabal file's ghc-options field, or in an {-# OPTIONS_GHC #-} pragma

I have the following program: data Peano = Zero | Succ Peano deriving (Show) add Zero b = b add (Succ a) b = add a (Succ b) mul Zero b = Zero mul (Succ a) b = add b (mul a b) four x = let two = Succ (Succ Zero) in mul two two I want to get something like this from GHC: add = \ ds b -> case ds of Zero -> b Succ a -> add a (Succ b) mul = \ ds b -> case ds of Zero -> Zero Succ a -> add b (mul a b) four = let two = Succ (Succ Zero) in mul two two The best I managed to get is ghci -ddump-simpl -dsuppress-module-prefixes -dsuppress-uniques foo.hs but it steel required a lot of manual removal of GHC

The standard Haskell's Double uses the standard double-precision arithmetic : data Double Double-precision floating point numbers. It is desirable that this type be at least equal in range and precision to the IEEE double-precision type. Does GHC/Haskell offer somewhere also the extended precision (80-bit) floating point numbers, perhaps using some external library? As chuff has pointed out, you might want to take a look a the numbers package on hackage. You can install it with cabal install numbers . Here is an example: import Data.Number.CReal -- from numbers main :: IO () main = putStrLn

I have a program written in Haskell and intended to be compiled with GHC. The program scales very well on multiple cores, so enabling multithreading is very important. In my .cabal file I've added ghc-options: -O3 -threaded to link with the threaded runtime. The problem is that with this approach the user would need to run the program with foo +RTS -N , which seems a bit cryptic and not very user friendly. How can I tell cabal/ghc to enable those runtime flags invisibly to the user? I've read about --with-rtsopts , but GHC (7.0.3) just spits out unrecognized flag when I try to use it. The flag