ghc

问题 I've got some code that compiles: {-# LANGUAGE ScopedTypeVariables, KindSignatures, GADTs, FlexibleContexts #-} module Foo where data Foo :: (* -> *) where Foo :: c m zp' -> Foo (c m zp) f :: forall c m zp d . Foo (c m zp) -> d f y@(Foo (x :: c m a)) = g x y g :: c m a -> Foo (c m b) -> d g = error "" The key thing I need in my real code is to convince GHC that if y has the type Foo (c m zp) and x has the type c' m' zp' , then c' ~ c and m' ~ m . The above code achieves this because I am able

问题 I'm trying to multiply array of units (from dimensional ) in a phantom type and I'm having trouble with functional dependencies. A simplified version of the problem is the following : I have the following type data F (a:: [*]) = F String Where the string represent an expression in a foreign language and a phantom type representing a list of types. I can do things like x = F "x" :: F '[Double] y = F "(1,3)" :: F '[Int, Int] I managed to implements arithmetics operators like this by creating a

问题 tl;dr: installed library with cabal sandbox, ghci still complains that the library is missing I have a directory where I am developing some Haskell stuff. This used to work fine on another computer, with ghc 7.6, but now that I'm working on another computer with ghc 7.8.2 (I don't know if the version would matter) I get errors like this: Prelude> :l Interpreter.hs Parser.hs:9:8: Could not find module ‘Text.ParserCombinators.Parsec’ Perhaps you meant Text.ParserCombinators.ReadPrec (from base)

问题 Original I'm trying to aggregate a CSV file and experiencing [what I consider to be] excessive memory usage and/or GC effort. The issue seems to arise when the number of groups increases. There is no problem when the keys are in the hundreds or thousands, but quickly starts spending a majority of time in the GC when the keys reach tens of thousands. Update Moving from Data.ByteString.Lazy.ByteString to Data.ByteString.Short.ShortByteString significantly reduced the memory consumption (to a

问题 Write a module: module Foo where foo = 3.14 Compile it: ghc -c Foo.hs Load it: ghci -ignore-dot-ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l Foo [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, modules loaded: Foo. Why won't GHCi pick up compiled code? Is it a bug in GHCi? I tried to run with -v , not too helpful. Update

问题 I've been teaching myself about type-level programming and wanted to write a simple natural number addition type function. My first version which works is as follows: data Z data S n type One = S Z type Two = S (S Z) type family Plus m n :: * type instance Plus Z n = n type instance Plus (S m) n = S (Plus m n) So in GHCi I can do: ghci> :t undefined :: Plus One Two undefined :: Plus One Two :: S * (S * (S * Z)) Which works as expected. I then decided to try out the DataKinds extension by

问题 I consider writing Haskell bindings to a quantum mechanics library written in C++ (I'd write a plain C wrapper) and CUDA. A major bottleneck is always the GPU memory used by the CUDA parts. In C++, this is handled quite efficiently because all objects have automatic memory management, i.e. are erased as soon as they leave scope. Also I use C++11 move semantics to avoid copies, those obviously wouldn't be necessary in Haskell anyway. Yet I'm concerned it might not work as smoothly anymore when

问题 I've been playing with the uncurry function in GHCi and I've found something I couldn't quite get at all. When I apply uncurry to the (+) function and bind that to some variable like in the code below, the compiler infers its type to be specific to Integer : Prelude> let add = uncurry (+) Prelude> :t add add :: (Integer, Integer) -> Integer However, when ask for the type of the following expression I get (what I expect to be) the correct result: Prelude> :t uncurry (+) uncurry (+) :: (Num a)

问题 I just installed GHC from the latest sources, and now my program gives me an error message about a "delayed read on closed handle". What does this mean? 回答1: The fundamental lazy I/O primitive, hGetContents , produces a String lazily—it only reads from the handle as needed to produce the parts of the string your program actually demands. Once the handle has been closed, however, it is no longer possible to read from the handle, and if you try to inspect a part of the string that was not yet

问题 When using the following in my stack.yaml to (attempt) to compile a static binary through Stack: ghc-options: "*": -static -optc-static -optl-static -optl-pthread -fPIC I get this error: usr/bin/ld: /usr/lib/gcc/x86_64-amazon-linux/4.8.3/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-amazon-linux/4.8.3/crtbeginT.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status `gcc'