January 2016 - Beginners

Multiline code in GHCi
by Shishir Srivastava 30 Aug '17

30 Aug '17

Hi, I am trying to run this basic multiline code in GHCi. I am not sure if this is even possible without writing it in a file and compiling it in a traditional way. ------- Prelude> :set +m Prelude> let main1 = do Prelude| a <- readLn Prelude| return a Prelude| Prelude> Prelude> main1 <interactive>:75:1: No instance for (Show (IO b0)) arising from a use of `print' In the first argument of `print', namely `it' In a stmt of an interactive GHCi command: print it ------- Could someone please confirm if the function can be defined and called like this in GHCi or point to where am going wrong. Thanks, Shishir Srivastava

5 9

generating object file for ARM
by Fabien R 06 Feb '16

06 Feb '16

Hello, I would like to link my Haskell module with existing object files for armv7-m. I use ghc 7.4.1 on debian/amd64. This command seems incorrect: ghc -pgmcarm-none-eabi-gcc -pgmParm-none-eabi-cpp -pgmaarm-none-eabi-as -pgmlarm-none-eabi-ld -keep-tmp-files HaskellModule.hs A lot of errors appeared: [1 of 1] Compiling HaskellModule ( HaskellModule.hs, HaskellModule.o ) /tmp/ghc13654_0/ghc13654_0.s: Assembler messages: /tmp/ghc13654_0/ghc13654_0.s:5:0: Error: unrecognized symbol type "" /tmp/ghc13654_0/ghc13654_0.s:17:0: Error: unrecognized symbol type "" /tmp/ghc13654_0/ghc13654_0.s:29:0: Error: bad instruction `leaq -40(%rbp),%rax' /tmp/ghc13654_0/ghc13654_0.s:30:0: Error: bad instruction `cmpq %r15,%rax' Any hints ? -- Fabien

2 2

Strange type error with hsc2hs and cabal
by PICCA Frederic-Emmanuel 31 Jan '16

31 Jan '16

Hello, I am still playing with FFI. Now I create a real project with cabal end build a library and an executable for my project. ---hkl.cabal--- name: hkl version: 0.1.0.0 executable ghkl main-is: ghkl.hs build-depends: base >=4.8 && <4.9 , containers >=0.5 && <0.6 , filepath , gtk >=0.13 && <0.14 , hkl hs-source-dirs: src default-language: Haskell2010 pkgconfig-depends: hkl build-tools: hsc2hs library exposed-modules: Hkl, Hkl.Types, Hkl.C, Hkl.DArray other-extensions: CPP, ForeignFunctionInterface, EmptyDataDecls, TypeFamilies, FlexibleInstances, FlexibleContexts, RecordWildCards build-depends: base >=4.8 && <4.9, containers >=0.5 && <0.6 hs-source-dirs: src build-tools: hsc2hs default-language: Haskell2010 pkgconfig-depends: hkl --- --- but when I compile my project I get this errormessage which is really strange. $ cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Warning: The package list for 'hackage.haskell.org' is 17.1 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Configuring hkl-0.1.0.0... Warning: 'data-files: ../../gui/ghkl.ui' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. Building hkl-0.1.0.0... Preprocessing library hkl-0.1.0.0... [1 of 4] Compiling Hkl.Types ( src/Hkl/Types.hs, dist/build/Hkl/Types.o ) [2 of 4] Compiling Hkl.C ( src/Hkl/C.hs, dist/build/Hkl/C.o ) [3 of 4] Compiling Hkl.DArray ( dist/build/Hkl/DArray.hs, dist/build/Hkl/DArray.o ) [4 of 4] Compiling Hkl ( src/Hkl.hs, dist/build/Hkl.o ) In-place registering hkl-0.1.0.0... Preprocessing executable 'ghkl' for hkl-0.1.0.0... [1 of 4] Compiling Hkl.Types ( src/Hkl/Types.hs, dist/build/ghkl/ghkl-tmp/Hkl/Types.o ) [2 of 4] Compiling Hkl.C ( src/Hkl/C.hs, dist/build/ghkl/ghkl-tmp/Hkl/C.o ) [3 of 4] Compiling Hkl ( src/Hkl.hs, dist/build/ghkl/ghkl-tmp/Hkl.o ) [4 of 4] Compiling Main ( src/ghkl.hs, dist/build/ghkl/ghkl-tmp/Main.o ) src/ghkl.hs:44:39: Couldn't match expected type ‘Hkl.Types.EngineList’ with actual type ‘Hkl.EngineList’ NB: ‘Hkl.Types.EngineList’ is defined in ‘Hkl.Types’ in package ‘hkl-0.1.0.0’ ‘Hkl.EngineList’ is defined at src/Hkl/Types.hs:22:1-74 In the first argument of ‘Hkl.engineListEnginesGet’, namely ‘engines’ In a stmt of a 'do' block: tmp <- Hkl.engineListEnginesGet engines if I add a other-modules to ghkl an remove the hkl dependecy it work great. so what is wrong with this project. PS: the DArray module is indeed the one using hsc2hs :) Thansk for your help Frederic

1 0

Is it possible to use a <> constructor in analogy to [] ?
by martin 29 Jan '16

29 Jan '16

Hello all, I've written my own Read and Show instances for a type, which is essentially data Crust a = Open [a] | Closed [a] "Show" does something like *Main> Closed [1,2,3] <1,2,3> *Main> Open [1,2,3] <1,2,3..> And Read faithully parses each stings and turns it into a Crust again. Problem is: when I just type <1,2,3..> in GHCi I get a "parse error on input ‘<’". However when I spell out the custructor as above it parses it okay. Is it possible at all to write my own <> constructor, or something like it=

2 1

Re: [Haskell-beginners] Custom type classes
by Guillaume Bouchard 29 Jan '16

29 Jan '16

May I suggest using FunctionalDependencies https://wiki.haskell.org/Functional_dependencies The class declaration is changed to class Indexable idx a | idx -> a where first :: idx -> a This just means that *a* is fully determined by idx (your tuple). Hence, instead of using as suggested first $ Tuple3 (1::Int) 'a' False::Int You can simplify and let the inference do its magic and use: first $ Tuple3 1 'a' False On Mon, Jan 25, 2016 at 8:42 AM, Imants Cekusins <imantc(a)gmail.com> wrote: > Hello Daniel, > > it works with these tweaks: > > -- begin > > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts #-} > module TupInst where > > > data Tuple3 a b c = Tuple3 a b c deriving (Show) > > data Tuple2 a b = Tuple2 a b deriving (Show) > > class Indexable idx a where > first :: idx -> a > > > instance Indexable (Tuple2 a b) a where > first (Tuple2 a0 b0) = a0 > > > instance Indexable (Tuple3 a b c) a where > first (Tuple3 a0 b0 c0) = a0 > > -- end > > call it in ghci like this: > > first $ Tuple3 (1::Int) 'a' False::Int > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

4 6

Increasing capabilities dramatically increases execution time
by Thomas Koster 28 Jan '16

28 Jan '16

Hi friends, I have encountered a situation in a concurrent program where I see an unexpected, dramatic increase in execution time when I add additional capabilities. On a multi-core CPU, "-N1" is fastest by an order of magnitude and the program increasingly slows for an increasing number of capabilities (still fewer than the number of real cores, of course). My question is, why is this so and what can I do to improve this? Some details: I have a shared data structure which I call a "store", which is basically a strict HashMap String Value. This structure is shared between Haskell threads using an IORef/MVar pair: data Store = Store (IORef (HashMap Key Value)) (MVar ()) Focus on the IORef/MVar pair - the HashMap itself is not important. My intention is that read-only transactions can take the pure value straight from the IORef without blocking writers or other readers, whereas mutating transactions (those that will update the IORef when they complete) are serialized using the MVar. Alternatively, you can regard the read-only transaction as working with a private snapshot of the store that is discarded after it completes. It is my hope that this technique will allow my program to exploit a multi-core CPU by running several read-only transactions and at most one mutating transaction in parallel. I am also assuming that this technique is marginally more efficient than STM for this use case, especially for write-heavy loads where I am assuming STM would waste some time on retries (I did not test this). -- | Execute a read-only transaction that returns a value. withStore :: Store -> (HashMap Key Value -> a) -> IO a withStore (Store ioref _) f = do store <- readIORef ioref return (f store) -- | Execute a transaction that updates the store and returns a value. modifyStore :: Store -> (HashMap Key Value -> (HashMap Key Value, a)) -> IO a modifyStore (Store ioref mvar) f = modifyMVar mvar $ \ z -> do store <- readIORef ioref let (store', x) = f store store' `seq` writeIORef ioref store' return (z, x) Stop me right here if this is a silly way to do this. I have a test that forks 4 threads that each increment a counter in the store 100000 times, with the expectation that the final answer is 400000. I use the "async" package for this. This test is not necessarily pathological. I expect simple operations like incrementing counters and concatenating text to be typical transactions. threads <- replicateM 4 $ async $ replicateM_ 100000 $ modifyStore store (...increment a counter...) forM_ threads wait In this test, while any thread is busy modifying the store, the other three are blocked on the empty MVar, irrespective of how many capabilities I have. Therefore, I expect the execution time with -N4 to be similar to -N1. I expect the only difference to be attributable to the runtime's scheduling overheads, which I assume are relatively insignificant. Instead, I see a dramatic increase in execution time with increasing capabilities (typical measurements below). By the way, I say I assume scheduling overheads are "relatively insignificant" compared to incrementing the counter because in my program, the counter is incremented by interpreting an imperative EDSL, which I assume is relatively inefficient compared to e.g. "succ", but perhaps I am mistaken. In a way, my whole question probably centres around this assumption. I would be grateful is anyone can illuminate the reason for this dramatic increase in execution time when I increase the number of capabilities, and any hints on how I can mitigate it. I am using GHC 7.10.2 and compile with -O -threaded. All library versions are as at Stackage LTS 3.2. A typical measurement, with -N1: Tot time (elapsed) Avg pause Max pause Gen 0 516 colls, 0 par 0.000s 0.003s 0.0000s 0.0001s Gen 1 2 colls, 0 par 0.000s 0.001s 0.0003s 0.0003s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.001s elapsed) MUT time 0.136s ( 0.139s elapsed) GC time 0.000s ( 0.003s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 0.136s ( 0.144s elapsed) With -N2: Tot time (elapsed) Avg pause Max pause Gen 0 334 colls, 334 par 0.012s 0.006s 0.0000s 0.0001s Gen 1 2 colls, 1 par 0.000s 0.000s 0.0002s 0.0003s Parallel GC work balance: 39.33% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N2) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.002s elapsed) MUT time 2.032s ( 2.456s elapsed) GC time 0.012s ( 0.007s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 2.044s ( 2.465s elapsed) With -N4: Tot time (elapsed) Avg pause Max pause Gen 0 133 colls, 133 par 0.032s 0.005s 0.0000s 0.0001s Gen 1 2 colls, 1 par 0.000s 0.001s 0.0003s 0.0003s Parallel GC work balance: 41.33% (serial 0%, perfect 100%) TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.003s elapsed) MUT time 3.516s ( 4.431s elapsed) GC time 0.032s ( 0.005s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 3.548s ( 4.439s elapsed) Thanks, Thomas Koster

2 2

FFI foreignPtr construction
by PICCA Frederic-Emmanuel 28 Jan '16

28 Jan '16

Hello, since the last time I think that I understand how to manage Ptr, now I woud like to masterize the ForeignPtr in order to let haskell managed the life of my C objects. So I try to create a Geoemtry object like this. -- data Geometry newtype Geometry = Geometry (Ptr Geometry) deriving (Show, Storable) newGeometry :: Factory -> ForeignPtr Geometry newGeometry f = unsafePerformIO $ do geometry <- c_hkl_factory_create_new_geometry f newForeignPtr c_hkl_geometry_free geometry foreign import ccall safe "hkl.h hkl_factory_create_new_geometry" c_hkl_factory_create_new_geometry :: Factory -> IO (Geometry) foreign import ccall safe "hkl.h &hkl_geometry_free" c_hkl_geometry_free :: FunPtr (Geometry -> IO ()) the C signature are HKLAPI HklGeometry *hkl_factory_create_new_geometry(const HklFactory *self) HKL_ARG_NONNULL(1); HKLAPI void hkl_geometry_free(HklGeometry *self) HKL_ARG_NONNULL(1); But when I try to compile this code, I get this error message 1 of 1] Compiling Hkl.C ( src/Hkl/C.hs, dist/build/Hkl/C.o ) src/Hkl/C.hs:51:33: Couldn't match type ‘Geometry’ with ‘Ptr Geometry’ Expected type: GHC.ForeignPtr.FinalizerPtr Geometry Actual type: FunPtr (Geometry -> IO ()) In the first argument of ‘newForeignPtr’, namely ‘c_hkl_geometry_free’ In a stmt of a 'do' block: newForeignPtr c_hkl_geometry_free geometry src/Hkl/C.hs:51:53: Couldn't match expected type ‘Ptr Geometry’ with actual type ‘Geometry’ In the second argument of ‘newForeignPtr’, namely ‘geometry’ In a stmt of a 'do' block: newForeignPtr c_hkl_geometry_free geometry I do not understand what is wrong in my code thanks if you can help Frederic

2 2

Parsing 'A's and then ('A's or 'B's)
by Simon Jakobi 27 Jan '16

27 Jan '16

Hi! I want to test whether a sequence of the characters 'A' and 'B' can represent a sequence of the symbols x and y where x may be represented by one or more 'A's and y may be represented by one or more 'A's or one or more 'B's. In code, I would like to see the following: λ> "AABB" `represents` [x, y] True λ> "AA" `represents` [x, y] True But with my current implementation using attoparsec only the first example works as expected: import Control.Applicative import Data.Attoparsec.ByteString.Char8 import Data.ByteString import Data.Either import Data.Foldable import Data.Word type Symbol = Parser [Word8] x :: Symbol x = many1 (char8 'A') y :: Symbol y = many1 (char8 'A') <|> many1 (char8 'B') represents :: ByteString -> [Symbol] -> Bool bs `represents` symbols = isRight $ parseOnly ((sequenceA_ symbols) *> endOfInput) bs It seems that in "AA" `represents` [x, y] x consumes all the 'A's, leaving none for y. Is it possible to solve this with attoparsec or are there other parsing libraries that I could use instead? Cheers, Simon

4 7

Ambigous type variable, why this error?
by martin 27 Jan '16

27 Jan '16

Hello all, here is something where I don't understand the second error: *Main> (Open [1,2,3]) <: (Open ([1,2,4])) <interactive>:94:8: No instance for (Num a0) arising from the literal ‘1’ The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ instance Integral a => Num (GHC.Real.Ratio a) -- Defined in ‘GHC.Real’ ...plus 46 others In the expression: 1 In the first argument of ‘Open’, namely ‘[1, 2, 3]’ In the first argument of ‘(<:)’, namely ‘(Open [1, 2, 3])’ Okay, I understand this one, but why this: <interactive>:94:16: No instance for (Poset a0) arising from a use of ‘<:’ The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance (Eq a, Ord a, Poset a) => Poset (Crust a) -- <== yes, yes, yes, take this one -- Defined at /home/martin/projects/haskell/currychicken/opal/Poset.hs:83:10 instance (Eq a, Ord a, Poset a) => Poset (PsSet a) -- Defined at /home/martin/projects/haskell/currychicken/opal/Poset.hs:50:10 instance (Eq a, Ord a, Poset a) => Poset (PsList a) -- Defined at /home/martin/projects/haskell/currychicken/opal/Poset.hs:46:10 ...plus one other In the expression: (Open [1, 2, 3]) <: (Open ([1, 2, 4])) In an equation for ‘it’: it = (Open [1, 2, 3]) <: (Open ([1, 2, 4])) The operands of (<:) are clearly Crusts, so (PsSet a) or (PsList a) shouldn't be options *Main> :t Open [1,2,3] Open [1,2,3] :: Num a => Crust a *Main> The problem goes away, when I make sure my list elements are Ints *Main> (Open [1::Int,2,3]) <: (Open ([1,2,4])) False But why do I see the second error at all? Here is the complete code: {-# Language FlexibleInstances #-} {-# Language UndecidableInstances #-} import qualified Data.List as L import qualified Data.Set as S import Debug.Trace import Test.QuickCheck hiding ((==>)) ------------------------------------------------------------ class Poset p where ------------------------------------------------------------ (<:) :: p -> p -> Bool instance Poset Int where (<:) = (==) ------------------------------------------------------------ -- Alternatives ------------------------------------------------------------ newtype PsList a = PsList [a] newtype PsSet a = PsSet (S.Set a) isSubPolist :: (Poset a) => [a] -> [a] ->Bool isSubPolist as bs = all includedInBs as where includedInBs a = any (a <:) bs instance (Eq a, Ord a, Poset a) => Poset (PsList a) where (PsList as) <: (PsList bs) = isSubPolist as bs instance (Eq a, Ord a, Poset a) => Poset (PsSet a) where (PsSet as) <: (PsSet bs) = isSubPolist (S.toList as) (S.toList bs) ------------------------------------------------------------ data Crust a = Open [a] | Closed [a] ------------------------------------------------------------ deriving (Eq, Ord, Show) instance (Eq a, Ord a, Poset a) => Poset (Crust a) where (<:) (Open as) (Closed bs) = False (<:) (Closed as) (Closed bs) = as == bs (<:) (Open _) (Open []) = True (<:) (Open []) (Open _) = False (<:) (Open (x:xs)) (Open (y:ys)) = x <: y && (Open xs) <: (Open ys) (<:) (Closed _) (Open []) = True (<:) (Closed []) (Open _) = False (<:) (Closed (x:xs)) (Open (y:ys)) = x <: y && (Closed xs) <: (Open ys)

2 1

compilation error for jhc
by Fabien R 25 Jan '16

25 Jan '16

Hello, I want to build jhc 0.82 on debian/amd64. I downloaded the sources and successfully configured the build. The compilation fails with this error: [149 of 186] Compiling Ho.Binary ( src/Ho/Binary.hs, src/Ho/Binary.o ) src/Ho/Binary.hs:164:10: Duplicate instance declarations: instance [overlap ok] Binary Data.Version.Version -- Defined at src/Ho/Binary.hs:164:10 instance [safe] Binary Data.Version.Version -- Defined in `binary-0.8.0.0:Data.Binary.Class' Makefile:1441: recipe for target 'jhc' failed The corresponding source code in src/Ho/Binary.hs is: import Data.Binary import qualified Data.Version instance Binary Data.Version.Version where put (Data.Version.Version a b) = put a >> put b get = liftM2 Data.Version.Version get get In the package binary, is this error due to this line ? import Data.Version (Version(..)) Any hint to solve this ? -- Fabien

2 2