November 2014 - Beginners

Haskell and LiveCode
by Frank 11 Nov '14

11 Nov '14

How do the 2 languages compare? -- P.S.: I prefer to be reached on BitMessage at BM-2D8txNiU7b84d2tgqvJQdgBog6A69oDAx6

1 0

Are these soloutions all valid and a good use of Haskell
by Roelof Wobben 10 Nov '14

10 Nov '14

Hello, I tried to solve the first problem of the 99 haskell problems on 3 seperate ways. The problem is that I have to find the last item of a list. The solutions I found with a little help of this mailinglist are : last2::[a]-> Maybe a; last2 [] = Nothing; last2 ([x]) = Just x; last2 (_:xs) = last2 xs last3::[a]-> Maybe a; last3 x | null x = Nothing | null xs = Just (head x) | otherwise = last3 (tail x) where xs = tail x last4::[a]-> Maybe a; last4 x = case x of [] -> Nothing ; [x] -> Just x ; (_:xs) -> last4 xs main = print $ (last2 [] ) What do you experts think of the different ways ? Roelof

7 14

First Project: Imperative Algorithm Visualization tool
by Adit Biswas 10 Nov '14

10 Nov '14

I'm kindoff a beginner in haskell, I've mostly just been exploring the language, some of the introductory books on the subject and writing some small programs. This is one of my first projects I wanted to try out, but I'm feeling a bit lost on how to go about doing it. I want to build a tool which takes in inputs describing algorithms, probably in their imperative form and generate animations using SVG and HTML5 preferably or OpenGL. I find that being able to visualize the execution of an algorithm helped me understand the material a few years ago when i started college but I mostly had to do these on pen and paper. So my higher level idea on approaching this problem is: 1. Create a dsl for describing data structures, e.g Link lists, trees, graphs 2. Create a dsl for describing each step of the algorithms manipulating the data structures 3. The algorithms would be a monadic composition of the step ADTs 4. Lift the algorithm to some monad which carries out the side effects of making changes to a visualization. I'm sorry if I didn't use all the correct terminology for describing the problem, I'm not completely sure if it's an appropriate approach. My logic was that Since each state of the visualization is a sideeffect of executing an algorithm, it would be a seperate monad like IO, the entire algorithm can be represented as some form of a graph, I should have data types representing each component of the graph. I have no idea how to go about designing a DSL or for designing a monad which will handle the animations. Could someone help me approach the solution and what topics I want to look at to understand how to build the solution. Feel free to let me know if you'd like to help work on the tool, or if you think I should simplify my project in some way. This is mostly just an idea for a project and since I'm feeling pretty beginnerish with the language, i wouldnt love suggestions on a simpler project which can sorta lead me in a direction in which i can make this tool in the future. Thank You! -- Adit Biswas

4 3

invalid type signature last2::: [a] -> a
by Roelof Wobben 09 Nov '14

09 Nov '14

Hello, I try to solve the 99 haskell problems on several ways. But my first try which looks like this : Last2::[a]-> a Last2:: last[list] gives the following error message : src/Main.hs@1:1-1:6 Invalid type signature: Last2 :: [a] -> a Should be of form <variable> :: <type> What am trying to do is say the input is a list which can be of integers or chars so everything is the output can then also be of type everything. Roelof

5 8

Re: [Haskell-beginners] Lazy state + IO not lazy?
by Jan Snajder 04 Nov '14

04 Nov '14

Dear all, On 10/27/14, Kim-Ee Yeoh <ky3(a)atamo.com> wrote: Kim-Ee, many thanks for your reply and sorry for my delayed reaction. > Consider > > let u = return () :: IO () in > expr >> u > > where expr ranges over (return undefined), (undefined), and (error "urk"). Ok, so this is what we get: (1) return undefined >> return () :: IO () ==> evaluates to 'IO ()' (2) > undefined >> return () *** Exception: Prelude.undefined (3) > error "urk" >> return () *** Exception: ur > Are their executions surprising? In my understanding, in a strict state monad, the '>>' operator will evaluate the (value,state) pair of the left expression up to the (,) constructor. Assuming this is correct, in (1) 'return undefined' gives a '(undefined,state)', which is not evaluated further, hence the computation continues. In (2), there is no 'return' to create a (value,state) pair, so when '>>' tries to evaluate the left expression, it evaluates directly to undefined. The same holds for error, which (I guess) stops the execution immediately upon being evaluated. Is my reasoning correct? > Compare to > > let u = return () :: State Int () in > evalState (expr >> u) 0 > > for both strict and lazy state. Ok, here we go: > Strict.evalState (return undefined >> return () :: Strict.State Int ()) 0 () > Strict.evalState (undefined >> return () :: Strict.State Int ()) 0 *** Exception: Prelude.undefined > Strict.evalState (error "urk" >> return () :: Strict.State Int ()) 0 *** Exception: urk > Lazy.evalState (return undefined >> return () :: Lazy.State Int ()) 0 () > Lazy.evalState (undefined >> return () :: Lazy.State Int ()) 0 () > Lazy.evalState (error "urk" >> return () :: Lazy.State Int ()) 0 () So, strict-state monad matches the behavior of 'IO', which is what I expected because I know 'IO' is a strict-state monad. Furthermore, lazy-state monad never inspects the left argument of '>>', so all three cases compute. > IO above matches one of them. Suppose > IO's behavior matches the other, what happens? I guess the IO monad would behave in an undesirable way because we would not be able to raise an exception nor catch undefined computations. Is that what you meant? > Now with the definition of mapM in mind, consider the difference > between your original: > > Lazy.evalStateT (head `fmap` mapM return (1:undefined)) 0 > > and > > Lazy.evalStateT (head `fmap` mapM return [1,undefined]) 0 > > Did you mean the latter? No, that's not what I meant. But I assume that in the latter case we won't get a bottom because we don't evaluate beyond the spine of the list: > Lazy.evalState (head `fmap` mapM return [1,undefined]) 0 1 > Lazy.evalStateT (head `fmap` mapM return [1,undefined]) 0 1 Is my interpretation correct? But what confuses me why we get different behavior here: > Lazy.evalState (head `fmap` mapM return (1:undefined)) 0 1 > Lazy.evalStateT (head `fmap` mapM return (1:undefined)) 0 *** Exception: Prelude.undefined From this I conclude that the second monad is strict, whereas the first is not. Is that correct? Assuming that is correct, does this mean that every monad stacked on top of an IO monad becomes strict?? Here's another example that illustrates this point: http://pastebin.com/0fAFmufA Why is (4) not computed in constant space, whereas (3) is? Finally, what ultimately bothers me is the following: is it true that if my state monad is built on top of an IO monad I cannot lazily consume a result of a mapM computation? (Here I am assuming, perhaps wrongly, that if '>>=' is non-strict in its left argument, then 'sequence' is tail recursive modulo cons. But I'm actually not convinced why this should be the case.) Many thanks for any input! Cheers, Jan

2 1