- Beginners - Haskell.org

RDBMS like references?
by martin 28 Jun '16

28 Jun '16

Hello all, I recently tried to model "Items", where an Item can either be inside another Item or at a certain location. I started like this: data Location i l = At l | In (Item i l) deriving (Eq, Show) data Item i l = Itm i (Location i l) deriving (Eq, Show) type ItemDb i l = [Item i l] ex_itemdb = let i1 = Itm 1 (At "a") i2 = Itm 2 (In i1) in [i1, i2] Now I wanted to move Item 1 to a different location using this code: moved = fmap f ex_itemdb where f (Itm 1 (At "a")) = (Itm 1 (At "b")) f x = x Not this does not do what I want. I get -- *Main> ex_itemdb -- [Itm 1 (At "a"),Itm 2 (In (Itm 1 (At "a")))] -- *Main> moved -- [Itm 1 (At "b"),Itm 2 (In (Itm 1 (At "a")))] While Item 1 has moved to "b" Item 2 still claims to be in an "Itm 1 (At "a")". I understand what's going on here and coming from a DB background I can see that the redundant data is the root of the problem. I can model this in a relational way such that the redundancy is avoided. But maybe there is a more haskellish/idiomatic way to acomplish this. Is there?

2 2

Strorable and incomplete type
by PICCA Frederic-Emmanuel 27 Jun '16

27 Jun '16

Hello, I would like to use Storable and declare an instance for a struct available in a C library instance Storable Parameter where sizeOf _ = #{size HklParameter} peek ptr = alloca $ \pmin -> alloca $ \pmax -> do cname <- c_hkl_parameter_name_get ptr name <- peekCString cname value <- c_hkl_parameter_value_get ptr unit c_hkl_parameter_min_max_get ptr pmin pmax unit min <- peek pmin max <- peek pmax return (Parameter name value (Range min max)) but when I try to compile this, I get this error message C.hsc:507:15: error: invalid application of ‘sizeof’ to incomplete type ‘HklParameter’ Indeed the C library do not expose this struct internal. So I would like to know how to handle this kind of C struct with Storable. thanks for your help Frédéric

1 0

Functions as containers; implications on being a Monad ((->) r)
by Raja 24 Jun '16

24 Jun '16

Everyone agrees ((->) r) is a Functor, an Applicative and a Monad but I've never seen any good writeup going into details of explaining this. So I was trying to brainstorm with my brother and went pretty far into the concept for quite a few hours, but still got stuck when it came to Monads. Before I showcase the question/problem I wanted to share our thinking process. Lets stick with common types like Maybe a, [a], simple function (a -> b) **Everything is a Container** Just 4 => this is a container wrapping some value [1,2,3] => this is a container wrapping bunch of values (+3) => this is a container wrapping domains & ranges (infinite dictionary) **When is a Container a Functor** If we can peek inside a container and apply a simple function (a->b) to each of its values and wrap the result back inside the container, then it becomes a Functor. Let's use (\x -> x+7) as simple function along with above three Containers (\x -> x+7) <$> Just 4 => Just 11 (\x -> x+7) <$> [1,2,3] => [8,9,10] (\x -> x+7) <$> (+3) => (+10) -- well there is no Show defined but you get the idea **When is a Container an Applicative** The simple function from above is also now wrapped inside a container and we should be able to peek to use it just like functor. Also lets simplify (\x -> x+7) to (+7). Just (+7) <*> Just 4 => Just 11 [(+7)] <*> [1,2,3] => [8,9,10] (\x -> (+7)) <*> (+3) => (+10) -- again no Show defined but works when pass a number -- but (+7) still needs to be wrapped in a Container though **When is a Container a Monad** This time we don't have a simple function (a->b) instead we have a non-simple function (a -> Container). But rest stays almost the same. We have to first peek inside a container and apply non-simple function to each of its values. Since its a non-simple function we need to collect all the returned Containers, unwrap them and wrap them all back in a Container again. (it almost feels like unwrap and wrapping them back is going to complicate things) Also Non-simple function cannot be reused as is for all three Containers like in Functors & Applicatives. Just 4 >>= (\x -> Just (x+7)) => Just 11 [1,2,3] >>= (\x -> [x+7]) => [8,9,10] (+3) >>= (\x -> (+7)) => (+7) Wait a minute ... the last line doesn't look right. Or should I say it doesn't feel right to discard the `x' altogether. OK let's jump to do this: (+3) >>= (\x -> (+x)) => ??? -- apparently this solves for the equation: f(x) = 2x + 3 (is 2x + 3 obvious for anyone??? it took us way longer to derive it) (Does it have anything to do with Monad laws by any chance?) This is where it feels like "Functions as containers" concept starts to breakdown; its not the right analogy for Monads. What does it even mean to unwrap a bunch of functions and wrap them back again? Hope this intrigues some of you as it did to us. Any thoughts and comments greatly appreciated. Thanks, Raja

4 3

Programming in Haskell - 2nd Edition
by Graham Hutton 21 Jun '16

21 Jun '16

Dear all, I'm delighted to announce that the 2nd edition of Programming in Haskell will be published in August 2016! The new edition has been extensively updated and expanded to include recent and more advanced features of Haskell, new examples and exercises, selected solutions, and freely downloadable lecture slides and example code. Further details, including how to preorder and obtain inspection copies, are provided below. Best wishes, Graham ================================================================= *** BOOK ANNOUNCEMENT *** Programming in Haskell - 2nd Edition Graham Hutton, University of Nottingham Cambridge University Press, August 2016 320 pages, 120 exercises, ISBN 9781316626221 http://tinyurl.com/PIH-2e ================================================================= DESCRIPTION: Haskell is a purely functional language that allows programmers to rapidly develop clear, concise, and correct software. The language has grown in popularity in recent years, both in teaching and in industry. This book is based on the author's experience of teaching Haskell for more than twenty years. All concepts are explained from first principles and no programming experience is required, making this book accessible to a broad spectrum of readers. While Part I focuses on basic concepts, Part II introduces the reader to more advanced topics. This new edition has been extensively updated and expanded to include recent and more advanced features of Haskell, new examples and exercises, selected solutions, and freely downloadable lecture slides and example code. The presentation is clean and simple, while also being fully compliant with the latest version of the language, including recent changes concerning applicative, monadic, foldable, and traversable types. ================================================================= CONTENTS: Foreword Preface Part I. Basic Concepts: 1. Introduction 2. First steps 3. Types and classes 4. Defining functions 5. List comprehensions 6. Recursive functions 7. Higher-order functions 8. Declaring types and classes 9. The countdown problem Part II. Going Further: 10. Interactive programming 11. Unbeatable tic-tac-toe 12. Monads and more 13. Monadic parsing 14. Foldables and friends 15. Lazy evaluation 16. Reasoning about programs 17. Calculating compilers Appendix A. Selected solutions Appendix B. Standard prelude Bibliography Index ================================================================= AUTHOR: Graham Hutton is Professor of Computer Science at the University of Nottingham. He has taught Haskell to thousands of students and received numerous best lecturer awards. Hutton has served as an editor of the Journal of Functional Programming, Chair of the Haskell Symposium and the International Conference on Functional Programming, and Vice-Chair of the ACM Special Interest Group on Programming Languages, and he is an ACM Distinguished Scientist. ================================================================= FURTHER DETAILS: The following web page includes details for how the book can be preordered, and how lecturers can obtain inspection copies: http://tinyurl.com/PIH-2e ================================================================= This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

2 1

default(Int)
by Imants Cekusins 16 Jun '16

16 Jun '16

default(Int) allows to use integers anywhere in this module without specifying their ambiguous type each time, like this: (3::Int) https://www.haskell.org/tutorial/numbers.html section 10.4 some other default types may be specified too somehow I was not aware of this

2 1

State Monad in constant space?
by martin 14 Jun '16

14 Jun '16

Hello all, the State Monad wraps around a computation s -> (s,a). Inside a do block I am actually assembling such a computation. Now when I do this many times, i.e. in a recursice call, I am builing a huge expression m a >>= (\a -> mb) >>= (\b -> mc) ... The result of this expression is a function s -> (s,a). But I cannot see how the space for this expression can be reclaimed, and how it could ever run in constant space. Once I call runState and I provide an initial s, I have some hope, but before? How is this supposed to work? How do I avoid allocating space for this huge expression?

3 2

How to hunt this space-leak
by martin 13 Jun '16

13 Jun '16

Hello all, I hope I am not asking for too much, as to explain my problem, you need to read my code, which may not be a pleasure. I am trying to write a "Logger", which formats and accumulates log-entries in a monoid. From there I went to writing an "accumulating" logger, i.e. one which can accumulate (sum/avg) over entries made with a certain timespan. My problen is memory consumption. In the test below I stress the logger with 1 million values, but in the end result, there are only 10 entries left, because it accumulates over 100,000. Memory goes up to apx 100MB. When I comment out the line, which logs the accumulated value (see -- > below), memory stays below 10MB. I dont understand why this is so. After all, the difference is only whether or not those 10 entries are logged or not. Can someone explain this? {-# LANGUAGE BangPatterns#-} import Data.Monoid import Control.Monad.State.Strict import System.TimeIt import Text.Show.Pretty import Debug.Trace ------------------------------------------------------------ -- Simple Time Stuff ------------------------------------------------------------ type Instant = Double type Interval = Double type Timed a = (Instant, a) instant = fst ------------------------------------------------------------ -- Logger based on State monad ------------------------------------------------------------ data SLogger a l = SLgr {runSLogger :: a ->State l (SLogger a l)} type SLogFormatter a l = a -> l accLogger :: (Monoid c, Show a) => (Instant, Interval, [Timed b]) -> SLogFormatter (Timed a) [Timed b] -> SLogFormatter [Timed b] [Timed c] -> SLogger (Timed a) [Timed c] accLogger (tx, dt, tas) fmt1 fmt2 = SLgr $ \(!ta) -> let x = fmt1 ta !tas' = x <> tas in if instant ta < tx then do -- keep accumulating return $ accLogger (tx, dt, tas') fmt1 fmt2 else do -- compute new log and reset accumulator !l0 <- get -- > put $ fmt2 tas' <> l0 return $ accLogger ((tx+dt), dt, []) fmt1 fmt2 accFmt1 ta = [ta] accFmt2 tas = [(fst $ head tas, "hello from accFormatter")] -- apply logger to a list of as stest lgr [] = return lgr stest lgr (a:as) = do lgr' <- (runSLogger lgr) a stest lgr' as main2 = do let as = zip [1.0 .. 1000000.0] [1..1000000] :: [(Instant, Int)] log = execState (stest (accLogger (100000.0,100000.0,[]) accFmt1 accFmt2 ) as) [(0,"init")] timeIt $ putStrLn $ ppShow log putStrLn "done" main = main2

2 1

Haskell and design patterns
by Dennis Raddle 09 Jun '16

09 Jun '16

I have been using Haskell on and off, as a hobbyist, for five years. I haven't been diligent in training myself on it, so I am learning slowly. It was confusing at first, coming from an imperative background. It occurred to me the other day that Haskell typeclasses are a kind of "design pattern." They identify a common pattern and provide a solution. I've been reading about design patterns in C++ for years. Haskell patterns are a twist on that. The imperative view looks at a task in a certain way, often conceiving of it as steps that mimic how human thoughts would go, and finding big general patterns that occur in different big applications. I don't want to speak for all of Haskell, but at least some Haskell patterns are smaller-scale and more attuned to the language of programming rather than the language of human thought. For instance, the Monad. The common use case is this---you have some "things," and you have a "container" that can accept more than one type of "thing." The common patterns are - you need to wrap things in the container - you need to unwrap things - you need to modify things while in their container - you have functions that operate on containers - you have functions that operate on the things, but maybe you don't want to unwrap them first. or maybe you do. To an imperative programmer, this is bizarre. What things are you talking about? What containers? You have not defined either one, so why can you say anything specific? Why all this emphasis on wrapping and unwrapping? Yet this is a design pattern all the same. It gets weird when you realize that the Maybe monad, conceived in human-thought terms, has totally different behavior than the list monad. Yet they are the same design pattern and have a relationship that is more concisely expressed mathematically than in human thought. The abundance of operators for wrapping/unwrapping/operating seems, if I understand right, closely related to the conciseness of Haskell. If you can use your containers without unwrapping them first, then by all means you don't want extra syntax just to do so. Same if you have functions that only operate on unwrapped things. Haskell patterns are "lightweight" also helping with the conciseness. The closest thing to a "container" in C++ is a class, which is a dozen times heavier than a Functor, Applicative, or Monad. Actually you really need a "template class" which is like a tank compared to Functor which is a skinny guy fighting with a short knife (who can usually get the job done just fine, thank you). Any comments welcome. I'm just trying to get a good perspective on Haskell. Mike

3 2

Re: [Haskell-beginners] Functions as containers; implications on being a Monad ((->) r)
by Alex Belanger 04 Jun '16

04 Jun '16

Does it help if I bring your: (\x -> x+7) <$> (+3) => (+10) It doesn't magically become `(+10)`. The previous step unseen is `(+7) . (+3)`. fmap for ((->) r) is defined as function composition `.`. fmap f g = f . g You can think of functors as containers or contexts; both analogies work well up to some degree (with the latter maybe more abstract and thus flexible). Another small terminology tip that could help you with your thinkering might be to call ((->) r) a partially applied function. Suddently, it narrows how you can potentially use/combine them. Last tip, Monad ((->) r) is commonly refered to as the Reader monad. Example of how it'd be used: doThings = do a <- (*2) b <- (+10) return (a + b) Notice how we can work with partially applied functions to which something have yet to be applied and create a new partial function whose argument is going to fill all the open holes. This isn't easy to explain without looking at the types of everything, so I encourage you to write it down and work out the types (: Alex On Jun 4, 2016 12:41 AM, "Raja" <rajasharan(a)gmail.com> wrote: Everyone agrees ((->) r) is a Functor, an Applicative and a Monad but I've never seen any good writeup going into details of explaining this. So I was trying to brainstorm with my brother and went pretty far into the concept for quite a few hours, but still got stuck when it came to Monads. Before I showcase the question/problem I wanted to share our thinking process. Lets stick with common types like Maybe a, [a], simple function (a -> b) **Everything is a Container** Just 4 => this is a container wrapping some value [1,2,3] => this is a container wrapping bunch of values (+3) => this is a container wrapping domains & ranges (infinite dictionary) **When is a Container a Functor** If we can peek inside a container and apply a simple function (a->b) to each of its values and wrap the result back inside the container, then it becomes a Functor. Let's use (\x -> x+7) as simple function along with above three Containers (\x -> x+7) <$> Just 4 => Just 11 (\x -> x+7) <$> [1,2,3] => [8,9,10] (\x -> x+7) <$> (+3) => (+10) -- well there is no Show defined but you get the idea **When is a Container an Applicative** The simple function from above is also now wrapped inside a container and we should be able to peek to use it just like functor. Also lets simplify (\x -> x+7) to (+7). Just (+7) <*> Just 4 => Just 11 [(+7)] <*> [1,2,3] => [8,9,10] (\x -> (+7)) <*> (+3) => (+10) -- again no Show defined but works when pass a number -- but (+7) still needs to be wrapped in a Container though **When is a Container a Monad** This time we don't have a simple function (a->b) instead we have a non-simple function (a -> Container). But rest stays almost the same. We have to first peek inside a container and apply non-simple function to each of its values. Since its a non-simple function we need to collect all the returned Containers, unwrap them and wrap them all back in a Container again. (it almost feels like unwrap and wrapping them back is going to complicate things) Also Non-simple function cannot be reused as is for all three Containers like in Functors & Applicatives. Just 4 >>= (\x -> Just (x+7)) => Just 11 [1,2,3] >>= (\x -> [x+7]) => [8,9,10] (+3) >>= (\x -> (+7)) => (+7) Wait a minute ... the last line doesn't look right. Or should I say it doesn't feel right to discard the `x' altogether. OK let's jump to do this: (+3) >>= (\x -> (+x)) => ??? -- apparently this solves for the equation: f(x) = 2x + 3 (is 2x + 3 obvious for anyone??? it took us way longer to derive it) (Does it have anything to do with Monad laws by any chance?) This is where it feels like "Functions as containers" concept starts to breakdown; its not the right analogy for Monads. What does it even mean to unwrap a bunch of functions and wrap them back again? Hope this intrigues some of you as it did to us. Any thoughts and comments greatly appreciated. Thanks, Raja _______________________________________________ Beginners mailing list Beginners(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

1 0

help on writing a typeclass
by Silent Leaf 04 Jun '16

04 Jun '16

I got a function, named mdk (don't ask). It happens it's a method of a class, as follows: class C a where mdk :: C b => a -> b -> (a, b) yet i got another function, called so far mdk' mdk' :: C b => b -> a -> (a, b) Say there are the following instances: instance C X where mdk x b = ... :: C b => (X, b) mdk' b x = ... :: C b => (X, b) instance C Y where mdk y b = ... :: C b => (Y, b) mdk' b y = ... :: C b => (Y, b) if you get what's happening, mdk and mdk' are basically the same method, save for the final type-result, which is reversed, without data loss mind you (aka (A, B) and (B, A) could be the same type, if only i knew of a way to make a type in haskell without forcing the order (a kind of set or something). so, there are four cases: input have types, in this order, X and Y, and expected output is (X, Y): then mdk from X's instance of C is called/must be used; input have types Y and X, output (X, Y): X's mdk' input X and Y, output (Y, X): Y's mdk input Y and X, output (Y, X): Y's mdk' it might seem confusing, but all amounts to the issue that even though (Y, X) is strictly equivalent, in my program, to (X, Y), in principle haskell differentiate the types. thus i have to write two versions of mdk for each type, even though the methods "X's mdk" and "Y's mdk'" are identical, and same for the two other methods. indeed: mdk :: C b => X -> b -> (X, b) mdk' :: C b => b -> Y -> (Y, b) are identical signatures, if in the first one you replace `b` with Y, and in the latter you replace `b` with X, and ofc if you consider (X,Y) == (Y,X). only one of those two methods should be enough to handle the job, and be chosen by the compiler on the sole value of the type of the first variable; but the fact both methods return tuples of "mirrored" types, crushes that. if i only write `mdk` instances, as soon as the compiler will meet this following signature: mdk :: a -> b -> (b, a) it will crash an exception, because mdk's original signature has for output value a tuple whose first type should here be `a`, because it's meant to be the type of the first argument, not the second. thus, at last my question: can i tell the compiler to consider (b, a) and (a, b) as identical types (don't worry it's not really a tuple in my program, but it's equivalent)? if not, can i make an overloading of mdk so it accepts both a->b->(a,b) and a->b->(b,a)? hope i didn't lose anyone. if so, do tell me, i'll try to clarify. thanks in advance of the time spent trying to understand my problem!

2 2