October 2010 - Beginners

Re: [Haskell-beginners] A few really short beginners questions
by Klaus Gy 04 Oct '10

04 Oct '10

Yea, Hugs tells me: ERROR (filepath):3 - Syntax error in instance head (constructor expected) But since I'm trying to understand Haskell and have nothing particular in mind with this program, I'm not stressed finding a solution for this. I'm happy if the code is principally correct. fweth 2010/10/3, Brent Yorgey <byorgey(a)seas.upenn.edu>: > On Sun, Oct 03, 2010 at 08:32:31PM +0200, Klaus Gy wrote: >> Thank You very much for the fast reply! I think I expressed myself >> badly in the first question. What does not work is the following: >> >> class Test a >> >> instance Num a => Test a > > What do you mean "doesn't work"? Do you get an error? Or it doesn't > have the behavior you expect? This ought to work fine. > > -Brent >

3 2

Re: [Haskell-beginners] A few really short beginners questions
by Klaus Gy 04 Oct '10

04 Oct '10

Thank You very much for the fast replies! I think I expressed myself badly in the first question. What does not work is the following: class Test a instance Num a => Test a Thanks, fweth 2010/10/3, Brent Yorgey <byorgey(a)seas.upenn.edu>: - Zitierten Text ausblenden - > On Sun, Oct 03, 2010 at 08:00:19PM +0200, Klaus Gy wrote: >> Hi! I have a few questions to improve my knowledge of Haskell. I >> didn't stumble over these problems while working on specific tasks, I >> more or less constructed them explicitly to get an adequate >> understanding of the basic Haskell semantics. >> >> 1 >> >> Why can't I apply a class directly to all instances of another, >> existing class? For example why is it possible to write >> >> class Test a >> >> instance Num a => Test [a] >> >> but not with >> >> instance Num a => Test a >> >> in the last row? > > Because these two instances are overlapping: if an instance for Test > [Int] was wanted, which instance should be chosen? Both 'Test [a]' and > 'Test a' match 'Test [Int]' so it is ambiguous. Now, it is possible > to turn on the OverlappingInstances flag, in which case the 'more > specific' instance (in this case Test [a]) would be chosen, but this > is generally considered bad for your health unless you Know What You > Are Doing (tm). > >> >> 2 >> >> Why is the following example not valid? >> >> f :: a -> a >> f '0' = 0 >> f x = 1 >> >> I think the reason lies in the type system but I can't locate it >> exactly. > > There is no type information around at runtime, so if f is supposed to > work for all types it must work *uniformly* for all types: it is not > possible to say "if the argument is a Char, do this; otherwise, do > that". > >> >> 3 >> >> Why is the following legal >> >> [] :: Num a => [a] >> >> but not with a self declared class instad of Num (unresolved >> overloading)? > > It should be possible with a self declared class. I'd have to see > more context to see why you are getting this error. > >> >> 4 >> >> Why does in the declaration >> >> f undefined = '0' >> >> the expression undefined work apparently in the same way as a >> wildcard? > > In a pattern, names simply match anything and bind that name to the > value. The fact that you have used the name "undefined" is not > relevant; it simply shadows any existing binding for the name > "undefined". So > > f blergh = '0' > > is precisely the same as > > f undefined = '0' > > Also, consider this example: > > x = 6 > > f x = 3 > f _ = 9 > > At first glance you might think that f yields 3 when passed 6 as an > argument and 9 for everything else; but in fact f always returns 3; > the two x's have nothing to do with one another. > > -Brent > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

3 3

Counting sheep with the State monad
by Amy de Buitléir 03 Oct '10

03 Oct '10

I've written a very simple piece of code in order to help me understand Monads better: ---------- import "mtl" Control.Monad.State countAnotherSheep :: Int -> (String, Int) countAnotherSheep n = (show n ++ " sheep", n+1) sheepCounter = State { runState = countAnotherSheep } ---------- So far so good. Now I can do things like: ghci> evalState sheepCounter 1 "1 sheep" ghci> evalState sheepCounter 2 "2 sheep" ghci> execState sheepCounter 1 2 ghci> execState sheepCounter 2 3 ghci> evalState (sequence $ replicate 5 sheepCounter) 1 ["1 sheep","2 sheep","3 sheep","4 sheep","5 sheep"] But what I really want to do is create a main function in which I: 1. Count some sheep. 2. Do something else. 3. Count some more sheep, picking up where I left off. I could thread the state like this: increment (_, n) = countAnotherSheep n main = do let c = countAnotherSheep 1 putStrLn $ fst c let c2 = increment c putStrLn $ fst c2 putStrLn "Now I'll do some other stuff" let c3 = increment c2 putStrLn $ fst c3 ... but shouldn't the State monad make threading the state unnecessary? It seems like there should be a way to do this, but I can't figure it out. Thank you in advance for any suggestions.

2 2

fromIntegral
by Russ Abbott 02 Oct '10

02 Oct '10

In explaining fromIntegral, I want to say that it is really a collection of overloaded functions: Integer -> Double Int -> Float ... When GHC compiles a line of code with fromIntegral it in, it must decide at compile time which of these overloaded functions to compile to. This is in contrast to saying that fromIngetral is a function of the type (Integral a, Num b) => a -> b. In reality there is no (single) function of the type (Integral a, Num b) => a -> b because (among other things) every function must map between actual types, but (Integral a, Num b) => a -> b does not say which actual types are mapped between. Is the preceding a reasonable thing to say? If so, can I say the same sort of thing about constants like 1 and []? In particular there is no single value []. Instead [] is a symbol which at compile time must be compiled to the empty list of some particular type, e.g., [Int]. There is no such Haskell value as [] :: [a] since [a] (as type) is not an actual type. I want to say the same thing about 1, i.e., that there is no such Haskell value as 1 :: (Num t) => t. When the symbol 1 appears in a program, the compiler must decide during compilation whether it is intended to be 1::Int or 1::Integer or 1::Double, etc. -- Russ Abbott ______________________________________ Professor, Computer Science California State University, Los Angeles Google voice: 424-242-USA0 (last character is zero) blog: http://russabbott.blogspot.com/ vita: http://sites.google.com/site/russabbott/ ______________________________________

7 18

Re: Beginners Digest, Vol 28, Issue 5
by C Gosch 02 Oct '10

02 Oct '10

I could be wrong, as I am also new to Haskell. I suppose the compiler simply cannot decide which type the lists you want to compare are (their constituent elements must be instances of class Eq, but more is not known). Adding type signatures will help the compiler (it should say so as well, check the error messages): testNull = ([]::[Int]) == ([]::[Int]) although I don't know why you would want to do such a thing (sorry I did not follow the whole thread). Cheers Christian 2010/10/2 <beginners-request(a)haskell.org> > Send Beginners mailing list submissions to > beginners(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/beginners > or, via email, send a message with subject or body 'help' to > beginners-request(a)haskell.org > > You can reach the person managing the list at > beginners-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Beginners digest..." > > > Today's Topics: > > 1. Re: fromIntegral (Russ Abbott) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 1 Oct 2010 22:52:34 -0700 > From: Russ Abbott <russ.abbott(a)gmail.com> > Subject: Re: [Haskell-beginners] fromIntegral > To: Daniel Fischer <daniel.is.fischer(a)web.de> > Cc: beginners(a)haskell.org > Message-ID: > <AANLkTikKF9g3MnGew5YkAK=xxszdiLHCd8a81Skqd6Kf(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > It turns out that > > test1 = 1 == 1 > > will load (and return True), but > > testNull = [ ] == [ ] > > won't load. Both 1 and [ ] seem to have similar sorts of type parameters in > their types. Why are they treated differently? > > > -- Russ > > > > On Fri, Oct 1, 2010 at 10:40 PM, Russ Abbott <russ.abbott(a)gmail.com> > wrote: > > > I can even write > > > > test = > > let x = [] > > y = 1 : x > > z = 'a' : x > > in ... > > > > But clearly I can't write tail y == tail z. Does that imply that type > > inferencing prevents one from writing a True expression? > > > > > > -- Russ > > > > > > > > On Fri, Oct 1, 2010 at 10:24 PM, Russ Abbott <russ.abbott(a)gmail.com > >wrote: > > > >> Thanks. I'm still wondering what [ ] refers to. I can load the following > >> file without error. > >> > >> null' xs = xs == [ ] > >> > >> test = > >> let x = [ ] > >> in tail [1] == x && tail ['a'] == x > >> > >> (I know I can define null' differently. I'm defining it this way so that > I > >> can ask this question.) > >> > >> When I execute test I get True. > >> > test > >> True > >> > >> So my question is: what is x after compilation? Is it really a thing of > >> type > >> (Eq a) => [a] ? > >> If so, how should I think of such a thing being stored so that it can be > >> found equal to both tail [1] and tail ['a']? Furthermore, this seems to > >> show that (==) is not transitive since one can't even compile > >> tail [1] == tail ['a'] > >> much less find them to be equal. Yet they are each == to x. > >> > >> -- Russ > >> > >> > >> > >> On Fri, Oct 1, 2010 at 9:08 AM, Daniel Fischer < > daniel.is.fischer(a)web.de>wrote: > >> > >>> On Friday 01 October 2010 17:08:08, Russ Abbott wrote: > >>> > Thanks, Filipe > >>> > > >>> > I clearly over-stated my case. I'd like to break it into a number of > >>> > different question. Please see below. > >>> > > >>> > On Thu, Sep 30, 2010 at 10:25 PM, Felipe Lessa > >>> <felipe.lessa(a)gmail.com>wrote: > >>> > > I'll try to clarify some concepts. Please correct me if I am > >>> > > wrong, and please forgive me if I misunderstood you. > >>> > > > >>> > > On Fri, Oct 1, 2010 at 12:54 AM, Russ Abbott < > russ.abbott(a)gmail.com> > >>> > > > >>> > > wrote: > >>> > > > In explaining fromIntegral, I want to say that it is really a > >>> > > > collection > >>> > > > >>> > > of > >>> > > > >>> > > > overloaded functions: > >>> > > > > >>> > > > Integer -> Double > >>> > > > Int -> Float > >>> > > > ... > >>> > > > > >>> > > > When GHC compiles a line of code with fromIntegral it in, it must > >>> > > > decide > >>> > > > >>> > > at > >>> > > > >>> > > > compile time which of these overloaded functions to compile to. > >>> > > > This is > >>> > > > >>> > > in > >>> > > > >>> > > > contrast to saying that fromIngetral is a function of the type > >>> > > > (Integral > >>> > > > >>> > > a, > >>> > > > >>> > > > Num b) => a -> b. In reality there is no (single) function of > the > >>> > > > type (Integral a, Num b) => a -> b because (among other things) > >>> > > > every function must map between actual types, but (Integral a, > Num > >>> > > > b) => a -> b does not say which actual types are mapped between. > >>> > > > > >>> > > > Is the preceding a reasonable thing to say? > >>> > > > >>> > > First of all, I do think that polymorphic functions are plain ol' > >>> > > functions. For example > >>> > > > >>> > > id :: a -> a > >>> > > id x = x > >>> > > > >>> > > is a function. Moreover, in GHC 'id' has only one > >>> > > representation, taking a thunk and returning a thunk, so even at > >>> > > the machine code level this is only one function. > >>> > > >>> > Agree. I over stated my case. The same can be said for > >>> > length :: [a] -> Int > >>> > It doesn't matter what the type of element in the list is. length > runs > >>> > the same way no matter what. So this is pure polymorphism. > >>> > > >>> > > Now, maybe 'fromIntegral' has something more than polymorphism? > >>> > > Well, it has typeclasses. But we can represent those as > >>> > > data types, so we could write > >>> > > > >>> > > fromIntegralD :: Integral a -> Num b -> a -> b > >>> > > fromIntegralD intrDictA numDictB = > >>> > > fromIntegral numDictB . toInteger intrDictA > >>> > > >>> > I'm afraid I don't understand this. Moreover, I couldn't get the > >>> > preceding to load without error. > >>> > > >>> > >>> No wonder, Integral and Num are type classes and not datatypes (unless > >>> you > >>> have defined such datatypes in scope). > >>> > >>> The point is, you can represent type classes as dictionaries, e.g. > >>> > >>> data Num a = NumDict > >>> { plus :: a -> a -> a > >>> , minus :: a -> a -> a > >>> , ... > >>> , fromIntegerD :: Integer -> a > >>> } > >>> > >>> data Integral a = IntegralDict > >>> { quotD :: a -> a -> a > >>> , ... > >>> , toIntegerD a > >>> } > >>> > >>> Then a type-class polymorphic function like fromIntegral becomes a > >>> function > >>> with some dictionaries as additional arguments. > >>> > >>> foo :: (Class1 a, Class2 b) => a -> b > >>> > >>> becomes > >>> > >>> fooDict :: Class1Dict a -> Class2Dict b -> a -> b > >>> > >>> To do that explicitly is of course somewhat cumbersome as one has to > >>> always > >>> carry the dictionaries around and one can have more than one dictionary > >>> per > >>> type (e.g. > >>> > >>> intNum1 :: Num Int > >>> intNum1 = NumDict > >>> { plus = (+) > >>> , ... > >>> , fromIntegerD = fromInteger > >>> } > >>> > >>> intNum2 :: Num Int > >>> intNum2 = NumDict > >>> { plus = quot > >>> , -- more nonsense > >>> , fromInteger = const 1 > >>> } > >>> ). > >>> > >>> Internally, GHC implements type classes via dictionaries and passes > them > >>> as > >>> extra arguments to overloaded functions, as you can see by inspecting > the > >>> Core output (-ddump-simpl). > >>> > >>> > > Better yet, the compiler could write this code for us internally. > >>> > >>> And GHC does. > >>> > >>> > > Now, using thunks we can get a single machine code for > >>> > > 'fromIntegralD' as well. > >>> > >>> But that's not terribly efficient, so with -O, GHC tries to eliminate > >>> dictionaries and use the specialised functions (like > >>> plusInteger :: Integer -> Integer -> Integer). > >>> > >>> > > > >>> > > In sum, I think all functions are really just that, functions. > >>> > > > >>> > > -- > >>> > > > >>> > > You may call functions that have typeclass constraints > >>> > > "overloaded functions", but they still are functions. > >>> > > > >>> > > Functions that are polymorphic but do not have constraints are > >>> > > not really overloaded because of parametricity, which means that > >>> > > they can't change the way they work based on the specific choices > >>> > > of types you make. > >>> > > >>> > I don't understand the preceding paragraph. Would you mind > elaborating. > >>> > > >>> > >>> For a function like > >>> > >>> length :: [a] -> Int > >>> > >>> , because it doesn't know anything about the type a at which it will be > >>> called, it cannot do anything with the contents of the list (well, it > >>> could > >>> call seq on them, but it would do that for every type), it can only > >>> inspect > >>> the spine of the list. > >>> > >>> The code is completely independent of what type of data the pointers to > >>> the > >>> contents point to, so `length [True,False]' and `length [()]' can and > do > >>> call the exact same machine code. > >>> > >>> > > > If so, can I say the same sort of thing about constants like 1 > and > >>> > > > []? In particular there is no single value []. Instead [] is a > >>> > > > symbol which at compile time must be compiled to the empty list > of > >>> > > > some particular type, e.g., [Int]. There is no such Haskell > value > >>> > > > as [] :: [a] since [a] (as type) is not an actual type. I want to > >>> > > > say the same thing about 1, i.e., that there is no such Haskell > >>> > > > value as 1 :: (Num t) => t. When the symbol > >>> > > > >>> > > 1 > >>> > > > >>> > > > appears in a program, the compiler must decide during compilation > >>> > > > whether > >>> > > > >>> > > it > >>> > > > >>> > > > is intended to be 1::Int or 1::Integer or 1::Double, etc. > >>> > > > >>> > > Well, [a] *is* an actual type, a polymorphic one. > >>> > > >>> > Here is the example that raised that issue for me. Let's say I define > >>> > null' as follows. > >>> > > >>> > null' xs = xs == [ ] > >>> > > >>> > If I don't include a declaration in the file, Haskell (reasonably) > >>> > concludes the following. > >>> > > >>> > > :t null' > >>> > > >>> > null' :: (Eq a) => [a] -> Bool > >>> > > >>> > If I write the following at the top level, > >>> > >>> You seem to mean the ghci prompt here, not the top level of a module. > >>> > >>> > everything is fine. > >>> > > >>> > > null' [ ] > >>> > > >>> > True > >>> > > >>> > But if I include the following in the file that defines null', I get > an > >>> > error message. > >>> > > >>> > test = null' [ ] > >>> > > >>> > Ambiguous type variable `a' in the constraint: > >>> > `Eq a' arising from a use of `null'' at null.hs:6:17-24 > >>> > Probable fix: add a type signature that fixes these type > >>> > variable(s) > >>> > > >>> > Why is that? > >>> > >>> null' has an Eq constraint, so to evaluate test, an Eq dictionary is > >>> needed, but there's no way to determine which one should be used. > >>> > >>> At a lower level, the type of null' is > >>> > >>> null' :: EqDict a -> [a] -> Bool > >>> > >>> The (hidden) first argument is missing and GHC doesn't know which one > to > >>> pass. > >>> > >>> At the ghci-prompt, ghci's extended default rules let it selet the Eq > >>> dictionary of () and all's fine. > >>> > >>> In a source file, GHC restricts itself to the default rules specified > in > >>> the language report, which state that for defaulting to take place, at > >>> least one of the constraints must be a numeric class. There's none > here, > >>> so > >>> no defaulting and the type variable of the constraint remains > ambiguous. > >>> > >>> > And how can it be fixed? I know I can fix it as follows. > >>> > > >>> > test = null' ([ ] :: [Integer]) > >>> > > >>> > > :reload > >>> > > > >>> > > test > >>> > > >>> > True > >>> > >>> In that situation, I think giving a type signature is the only wayน. > >>> > >>> test = null' ([] :: Num a => [a]) > >>> > >>> also works. > >>> > >>> น -XExtendedDefaultRules might work too. > >>> > > >>> > That's what suggested to me that [ ] had to be compiled into a > concrete > >>> > value. > >>> > >>> Try > >>> > >>> null'' [] = True > >>> null'' _ = False > >>> > >>> test'' = null'' [] > >>> > >>> No type class constraints, no problems. > >>> > >>> > > >>> > > >>> > It seemed to me that similar reasoning applied to things like 1. How > >>> is > >>> > the following explained? > >>> > > >>> > Prelude> 111111111111111111111111111111111111111111 > >>> > 111111111111111111111111111111111111111111 > >>> > it :: (Num t) => t > >>> > Prelude> maxBound :: Int > >>> > 2147483647 > >>> > it :: Int > >>> > Prelude> 111111111111111111111111111111111111111111 - (1::Int) > >>> > -954437178 > >>> > it :: Int > >>> > > >>> > Does it make sense to say that the long string of 1's is really of > type > >>> > (Num t) => t? > >>> > >>> Integer literals stand for (fromInteger Integer-value-of-literal), so > the > >>> literal itself can have any type belonging to Num. If you force it to > >>> have > >>> a particular type, the corresponding fromInteger function is determined > >>> and > >>> can be applied if the value is needed. > >>> > >>> > > >>> > If so, what does the compiler think it's doing when it processes(?) > it > >>> > as an Int so that it can subtract 1 :: Int from it? It didn't treat > it > >>> > as maxBound :: Int. And yet it didn't generate an error message. > >>> > >>> For efficiency, fromInteger wraps, for a b-bit Integral type, the > result > >>> of > >>> fromInteger n is n `mod` 2^b. > >>> > >>> > > >>> > Thanks > >>> > > >>> > -- Russ > >>> > >>> > >> > > >

2 1

type of zipWithPlus
by Russ Abbott 02 Oct '10

02 Oct '10

When I define zipWithPlus at the top level of GHCi, the type is as shown. > let zipWithPlus = zipWith (+) zipWithPlus :: [Integer] -> [Integer] -> [Integer] Why isn't it: (Num a) => a -> a-> a I was unable to find a way to get the type to be more general. I tried various declarations within the let using (Num a) => a -> a-> a but none of them were accepted. Thanks. -- Russ Abbott ______________________________________ Professor, Computer Science California State University, Los Angeles Google voice: 424-242-USA0 (last character is zero) blog: http://russabbott.blogspot.com/ vita: http://sites.google.com/site/russabbott/ ______________________________________

3 3

Applicative Composition
by edgar klerks 01 Oct '10

01 Oct '10

Hi All, I was wondering, why there isn't a composition operator for applicative functors. Of course it is rather trivial to implement, but it is a useful feature: {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module ApplicativeComposition where import Control.Applicative class (Applicative f) => ApplicativeComposition f where (<.>) :: f (b -> c) -> f (a -> b) -> f (a -> c) instance (Applicative f) => ApplicativeComposition f where (<.>) f g = pure (.) <*> f <*> g Can this be added to later versions of haskell? Greets, Edgar

4 3

Fwd: [Haskell-beginners] Applicative Composition
by Antoine Latter 01 Oct '10

01 Oct '10

Forwarding to list - it looks like I forgot to reply-all. ---------- Forwarded message ---------- From: Antoine Latter <aslatter(a)gmail.com> Date: Thu, Sep 30, 2010 at 7:17 PM Subject: Re: [Haskell-beginners] Applicative Composition To: edgar klerks <edgar.klerks(a)gmail.com> On Thu, Sep 30, 2010 at 6:47 PM, edgar klerks <edgar.klerks(a)gmail.com> wrote: > Hi All, > > I was wondering, why there isn't a composition operator for applicative > functors. Of course it is rather trivial to implement, but it is a useful > feature: > > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} > module ApplicativeComposition where > import Control.Applicative > > class (Applicative f) => ApplicativeComposition f where > (<.>) :: f (b -> c) -> f (a -> b) -> f (a -> c) > > instance (Applicative f) => ApplicativeComposition f where > (<.>) f g = pure (.) <*> f <*> g > > Can this be added to later versions of haskell? > Here's the last time this topic came up on the lists: http://www.haskell.org/pipermail/libraries/2010-August/013992.html Here's the corresponding library proposal ticket: http://hackage.haskell.org/trac/ghc/ticket/4189 There were a few folks against it for a few different reasons. Antoine

2 2