December 2012 - Beginners

Couldn't match expected type with actual type
by Alexander _ 07 Dec '12

07 Dec '12

Hello, I have function with following signature: get :: a -> Value b I don't know concrete type of b. It can be Value Int or Value String or something else. How can i to write function only for testing? I need something like this: get :: a -> Value b get k = (Value "some_data"') but i got error: Couldn't match expected type `b' with actual type `[Char]' `b' is a rigid type variable bound by the type signature for get :: a -> Value b at Test.hs:39:8 In the first argument of `Value', namely `"some_data"' In the expression: (Value "some_data") In an equation for `get': get k = (Value "some_data") Failed, modules loaded: none. Value data declaration: data Value b = Value b deriving (Show) Thank you.

3 2

(:
by Ezequiel Hernan Di Giorgi 06 Dec '12

06 Dec '12

this code compiles correcly: newtype State s a = State { runState :: *s* -> (a,s) } instance Monad (State s) where --return :: a -> State s a return x = State (\st -> (*x,st*)) but this one doesn't compile: newtype State s a = State { runState :: *a* -> (a,s) } instance Monad (State s) where --return :: a -> State s a return x = State (\st -> (*st,x*)) Why is this happening?

2 1

Illegal datatype context when modelling round robin scheduler
by Xiao Jia 06 Dec '12

06 Dec '12

Hi, I'm trying to model a round robin scheduler in Haskell. > class Schedulable s where > isFinal :: s -> Bool > > class Scheduler s where > add :: (Schedulable a) => a -> s -> s > next :: (Schedulable a) => s -> (a, s) > empty :: s -> Bool > > data Schedulable a => RoundRobin = RoundRobin [a] [a] > > instance Scheduler RoundRobin where > add p (RoundRobin ps qs) = RoundRobin (ps ++ [p]) qs > > next (RoundRobin [] qs) = next (RoundRobin qs []) > next (RoundRobin (p:ps) qs) = (p, RoundRobin ps (qs ++ [p])) > > empty (RoundRobin [] _) = True > empty _ = False However, GHC complains that > main.hs:9:6: > Illegal datatype context (use -XDatatypeContexts): Schedulable a => After some searches I realized that datatype contexts are deprecated. So how can I model the scheduler without using datatype contexts? Thanks. -- Regards, Xiao Jia

3 4

partial application
by Miguel Negrao 04 Dec '12

04 Dec '12

Hi list, Is there a syntax in Haskell for partial application that would be something like this the following ? f a b c d = a +b+ c+ d g = f _ 1 2 3 or the only way to do it is like below ? g = (\x -> f x 1 2 3) Also, hlint complains about top-level functions without type even if they are not exported out of the corresponding module. Is is really bad style not put type signatures in all top-level functions ? I really like the fact that haskell takes care of the type signatures for me. best, Miguel http://www.friendlyvirus.org/miguelnegrao/

4 3

implicit deletion of ghci history
by Christopher Howard 04 Dec '12

04 Dec '12

This may sound like a strange question, but are there any commands or activities in ghc / ghci / cabal that implicitly delete your ghci history? A few times in the last few days I've started ghci, to find I only had about five or ten commands in my history, even though I execute dozens of commands each day. However, if I quickly close and reopen ghci, the commands that I just entered are still there. I can't think of anything unique to my system that would cause this, unless maybe Emacs is doing something weird with it in Haskell mode. I'm running Gentoo Linux (amd64) with GHC 7.4.1 and cabal-install 1.16.0.2. -- frigidcode.com

1 0

fibonacci and concurrent recursion
by Christoffer Buchholz 03 Dec '12

03 Dec '12

Hi I have been looking at this fibonacci implementation: f = 0:1:(zipWith (+) f (tail f)) and I have been trying to fit it inside my head. I am not quite there yet, though. I have been tracing the steps manually like this 0:1 [0,1] [1] 0:1:1 [0,1,1] [1,1] 0:1:1:2 [0,1,1,2] [1,1,2] 0:1:1:2:3 [0,1,1,2,3] [1,1,2,3] 0:1:1:2:3:5 And it is easy to see that it works, but what I do not understand is how the two recursive applications progress. How do they evolve concurrently? For each execution of `f`, `f` will be executed twice. So how does all these results end up in the same list? I guess a more general way of asking my question is how does concurrent recursion on the same result-set work? -- Christoffer Buchholz

3 5

Re: [Haskell-beginners] partial application
by Brent Yorgey 03 Dec '12

03 Dec '12

On Mon, Dec 03, 2012 at 03:20:41PM +0000, Miguel Negrao wrote: > > A 03/12/2012, às 12:53, Brent Yorgey escreveu: > >> Is there a syntax in Haskell for partial application that would be something like this the following ? > >> > >> f a b c d = a +b+ c+ d > >> > >> g = f _ 1 2 3 > > Yes, a lambda is the only way to do it. > > Given how compact haskell’s syntax can be, is there a reason why implementing such placeholders is not a good idea for haskell ? Yes: it would introduce horrible ambiguity. Consider (f (g _ 1 2)) Does it mean (f (\x -> g x 1 2)) or (\x -> f (g x 1 2)) ? I don't know of any good reason to prefer one over the other. Any rule you come up with is likely to have other weird corner cases you hadn't considered. As I understand it, Scala actually does have this feature, along with lots of confusing, ugly, ad-hoc rules to disambiguate situations like the above. > > 2. Suppose you make a mistake when implementing a function. If you > > don't give a type signature, it's possible that GHC will infer > > some type for it anyway (but not the type you intended!). Now > > you will not get an error until further down the line when you > > use that function somewhere else. And what's more, the error > > will not tell you anything about the real problem. It will just > > say "X does not match Y on line 297" and you will have to do a > > lot of work to figure out that the real problem is that you > > messed up in implementing function foo on line 43. But if you > > had put a type signature on foo in the first place, you would > > have gotten an error immediately. > Ok, I see your points. Number 2 does happen to me from time to > time, at which point I go back to the a point where the code worked > and introduce the type signatures with hlint, so yeah doing the > signatures would save me from having to do that. Sometimes I know > how to write a function but I don’t know how to write the type > signature because they are too complicated for my still reduced > knowledge of haskell, for instance, I don’t know when I need to use > the forall thing, which hlint sometimes introduces when it produces > the type signatures. Perhaps the problem might be that I should be > using less top-level functions and defining some of those functions > where they are used ? A lot of my top-level functions are used only > in one place in the code, I just code them as top-level so that I > can test them in ghci if I need to. No, I don't think using less top-level functions will solve anything. In the case where you don't know how to write a type because it is too complex, or requires features you don't understand, I think it is reasonable to write it, ask GHCI for its type signature, make sure it looks reasonable, and then add it to your file. But I would hope this situation makes up a minority of cases. One could also question the wisdom of writing code that requires type system features you don't understand. -Brent

2 1

Precedence of type annotation operator ::
by José Romildo Malaquias 02 Dec '12

02 Dec '12

Hello. What is the exact precedence of the type annotation binary opertor :: ? Romildo

2 1

my fist program
by Ezequiel Hernan Di Giorgi 02 Dec '12

02 Dec '12

Hola! Hallo! I made my first program to understand lists and something about datat types. I have some question about the following code... * import* Data.List *data* Student = Student { id :: Int, nombre :: String } *deriving* (*Show*, *Eq*) main :: IO ()main = *do* putStrLn "---\nStudent Magnament Program\n---" loop [] ashow :: [Student] -> IO ()ashow [] = putStrLn "Empty list"ashow [x] = putStrLn $ show xashow (x:xs)= *do* putStrLn $ show x ashow xs aadd :: [Student] -> IO ()aadd xs = *do* putStrLn "Enter the id" id <- getLine putStrLn "Enter name" name <- getLine loop $ (Student (read id) (read name) ) : xs aremove :: [Student] -> IO ()aremove xs = *do* putStrLn "Enter the id" id <- getLine putStrLn "Enter name" name <- getLine loop $ delete (Student (read id) (read name) ) xs loop :: [Student] -> IO ()loop xs = *do* putStr $ "\n-------\nSelect an option\n" ++ "1) Add student\n" ++ "2) Remove student\n" ++ "3) Show all students\n" ++ "4) Exit\n" ++ "\t Your option: " option <- getLine putStrLn "\n------" *case* read option *of* 1 -> aadd xs 2 -> aremove xs 3 -> *do* ashow xs loop xs 4 -> putStrLn "God bye!" My question are: - When i ask for the data fof a student i repeat the code, cause i have to use fuctions using IO (), cuase i have to put something in the screen. Therefore i cant have a fuction that only return a Student. - loop $ (Student $ read id $ read name), is wrong why? - i think that there are best way to achive that i have done. Or is ok for a begginer that doesn't know functors or monads. Sorry for my bad english, i am Argentinean. Thanks in advance.

3 2

The application of application
by Christopher Howard 02 Dec '12

02 Dec '12

Can application of an expression (to a function) be treated like a function itself? In my specific case, I started with this expression: code: -------- (cos b * velocityC, sin b * velocityC) -------- But I have a compulsive hatred of duplication. I happened to have this function handy called appPair: code: ------- appPair f (a, b) = (f a, f b) appPair (* velocityC) (cos b, sin b) ------- Better, but the b identifier is still duplicated. Is there some way I could have... code: -------- appPair (?) (cos, sin) -------- ...shifting the application of b into the (* velocityC) expression, without modifying my appPair function? -- frigidcode.com

4 4