September 2015 - Beginners

Multiline code in GHCi
by Shishir Srivastava 29 Aug '17

29 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

Haskell package maturity
by Andrew Bernard 01 Oct '15

01 Oct '15

Since starting to look on Hackage for packages for such vital things as queues and algorithms, I am surprised to see very low numbers of downloads for packages that seem to me to be vitally important. For example, queuelike has only been downloaded 1617 times since being uploaded in 2009. Similar very low numbers seem to apply for many packages. Another example is cubicspline with only 485 downloads. My question is, are the numbers on Hackage correct, and if so, do they indicate hardly anybody uses them, or indeed Haskell? I am starting to wonder. I also notice version numbers are very low, often less than one and most often around 0.1 or so. This is either a display of extreme modesty on the part of Haskell library code developers (in fact, often found in open source communities), or an indication of lack of maturity of the code. Overall I am puzzled about this. I am trying to establish what packages to use in my coding and there seems to be little indication of what to choose, and how to assess code maturity. What am I missing? Andrew

10 10

State and Maybe and monad transformers
by Andrew Bernard 30 Sep '15

30 Sep '15

Greetings All, I am writing code using a BankersDequeue from Data.Dequeue. I’d like to wrap the push and pop operations in a state monad for the standard reason, to avoid passing the dequeue around between function calls, and regard it as state instead, which it is. Wishing to avoid throwing a runtime error if the queue is empty (for the general case of queues) I have written a reduction of the concept using a crude stack to experiment, which uses State and Maybe. I notice that there are very few examples of using State and Maybe together. My questions are: Is this a faulty design pattern? Should this be done with monad transformers? Are there examples to be found of using State with Maybe as a monad transformer combination? Why is this pattern relatively rare, it seems? Is this program on the right track? Andrew — snip module Main where import Control.Monad.State type Stack = [Int] popIt :: Stack -> (Maybe Int, Stack) popIt [] = (Nothing, []) popIt (x:xs) = (Just x, xs) pop :: State Stack (Maybe Int) pop = state popIt push :: Int -> State Stack (Maybe ()) push a = state $ \xs -> (Just (), a:xs) main = do let a = evalState (do push 3 push 2 push 1 pop pop a <- pop return a ) [] print a — snip

2 1

Help with a data type declaration
by jamb＠hinojosa.com 29 Sep '15

29 Sep '15

How can I interpret the following data type declaration? The book where I am studying (and other sources I have read as well) only show more simple examples. This is what I can say about it: * "Tree" is the name of the new type. * "Branch" and "Leaf" are the type constructors. * What is "a" and "b"? * It seems to me that this type is kind of "recursively" defined but I do not know exactly. data Tree a b = Branch b (Tree a b) (Tree a b) | Leaf a I will very much appreciate your feedback. Regards, JAMB

5 5

Optimising a combinatorial algorithm?
by Mario Lang 29 Sep '15

29 Sep '15

Hi! TL;DR: My implementation looks elegant (to me), but is rather slow compared to a well optimized C++ impl. of the same algorithm. Runtime differences are currently huge. Looking for input on what I could change to match C++ performance, without loosing too much expressiveness of the code. I am writing software to deal with Braille music code. As an exercise for me, and as an attempt to boil the algorithm down to a more readable form, I am in the process of translating my C++ program[1] to Haskell. So far, so good. Given that I only came back to Haskell (after 10 years of a break) roughly 2 weeks ago, I think I have made quite nice progress. However, now that I reached a stage where I can actually do a performance comparison, the dreaded thing has happened: The performance of my Haskell implementation is rather horrible to what my C++ implementation can deliver. While the code size has gone down roughly by a factor of 10, runtime has gone up roughly by the same factor... For the impatient, here is the code I am talking about: https://github.com/mlang/hbmc/blob/master/Data/Braille/Music.hs The first half of the code is concerend with parsing braille. Performance is not critical here, so I opted to use Parsec, mostly because I am interested in good quality error messages. The fun starts with the definition of 'pvs'. The problem: Braille music values are inherently ambiguous. The sign for a whole note can also mean a 16th note, a sign for a half note can also mean a 32th note, the sign for a quarter note can also mean a 64th, and a 8th note could also mean a 128th note. This is histoical, and there is no way around this. The time signature (meter) is used to actually tell which note is which. This is relatively easy to do for an experienced human, but quite complicated for a computer. A measure (bar) of braille music can contain parallel *and* sequential parts. The data structure is basically: data Sign = ... type PartialVoice = [Sign] type PartialMeasure = [PartialVoice] type Voice = [PartialMeasure] type Measure = [Voice] As a constraint, all PartialVoices in a PartialMeasure need to have the exact same duration. Similarily, all Voices inside a Measure also need to have the exact same duration. So 'pvs', 'pms', 'vs' and 'ms' in my Data.Braille.Music module are concerned with calculating all possible interpretations of the input. All in all, the current Haskell implementation is doing what it should. However, profiling tells me I am allocating roughly 2GB of memory to disambiguate a single measure of music in 3/2 time. This takes roughly 1.2s on my rather fast CPU. The amount of allocation and the runtime are unacceptable. If I leave it at that, I might as well ditch the code and terminate the experiment. As a comparison, my C++ impl. takes roughly 1s to disambiguate 32 measures of the same piece, while Haskell already takes 1.2s to disambiguate just one of these measures. Profiling tells me I am spending 90% of all the time in 'dur', which is my small helper method to calculate the duration of a PartialVoice, PartialMeasure or Voice. The project is setup to support profiling: git clone https://github.com/mlang/hbmc cd hbmc cabal run profiling Do you see a way to significantly speed this algorithm up, without loosing a lot of expressiveness/elegancy? Since I am back to Haskell since only 2 weeks, I am basically happy abut every sort of hint/tip you can give me. Stylistic, as well as performance-related. For now, this is really just a toy project. However, if I can manage to improve the performance significantly without destroying the readability of the code too much, I might be interested to finish translating my current C++ work into a more-or-less complete Haskell library. After all, BMC is more or less a compiler. And Haskell is supposed to be very good at this stuff :-) Here is a link to the original C++ project: [1] https://github.com/malng/bmc -- CYa, ⡍⠁⠗⠊⠕

6 8

foldl on Bool:s
by goforgit . 27 Sep '15

27 Sep '15

Reading http://learnyouahaskell.com/higher-order-functions I understand that with the function sum' :: (Num a) => [a] -> a sum' = foldl (+) 0 the call ghci>>> sum' [1,2,3] will be evaluated as 0 + 1 + 2 + 3 = 6 But what about the function elem' :: (Eq a) => a -> [a] -> Bool elem' y ys = foldl (\acc x -> if x == y then True else acc) False ys and calling it with ghci>>> elem' 3 [1,2,3] How is that evaluated to True by foldl in elem'? Thanks in advance for any explanation to this!

3 4

Get max element of a list using foldl or foldr
by jamb＠hinojosa.com 25 Sep '15

25 Sep '15

Hello, I am a complete Haskell beginner and I am doing some exercises of my book but I am stuck with the following: Define myMax :: Ord a => [a] -> a which returns the maximum element of a list. I must use foldl1 or foldr1 and I am given the hint to use max which gets the maximum of 2 elements. I will very much appreciate if you help me solve it. Thanks in advance, JAMB

4 4

Numeric Integer vs Integer
by goforgit . 25 Sep '15

25 Sep '15

Hello! Could someone explain to me the difference between the following? data Atype = Numeric Integer | A | B C and data Atype = Integer | A | B C Thanks in advance!

5 10

applicative style
by Williams, Wes(AWF) 24 Sep '15

24 Sep '15

Hi haskellers, I am trying to understand why I get the following error in learning applicative style. Prelude> let estimates = [5,5,8,8,2,1,5,2] Prelude> (/) <$> Just $ foldl (+) 0 estimates <*> Just . fromIntegral $ length estimates <interactive>:54:1: Non type-variable argument in the constraint: Fractional (Maybe r) (Use FlexibleContexts to permit this) When checking that 'it' has the inferred type it :: forall a r. (Fractional (Maybe r), Num a, Num (Int -> Maybe a -> r)) => Maybe r -> Maybe r All the parts work individually. If use let and assign the parts to x and y it also works. E.g. This works let x = Just $ foldl (+) estimates Let y = Just . fromIntegral $ length estimates (/) <$> x <*> y I clearly do not understand exactly how these work. :-) Thanks for any help, -wes

4 3

Monad transformers
by Andrew Bernard 19 Sep '15

19 Sep '15

Greetings All, While I admire Haskell enormously, as a an intermediate beginner I find it difficult to know what is normal Haskell style for real world programming. On the subject of monad transformers, the paper by Martin Grabümller titled 'Monad Transformers Step by Step' gives an example of an evaluator using monad transformers with the following type: type Eval6 α = ReaderT Env (ErrorT String (WriterT [String] (StateT Integer IO))) α Is this how normal Haskell is developed and written in practice? I find the type and the function impenetrably dense and difficult to understand. Should I be aspiring to have my functions look and work like this? Of course it depends on what you want to do, but the essence of the question is, does Haskell ultimately end up looking like this for any real programming, beyond textbook list manipulation functions? Andrew

6 6