March 2012 - Haskell-Cafe

blog software in Haskell?
by Ketil Malde 30 Mar '12

30 Mar '12

Hi, I just upgraded my server, and set up everything again. Except wordpress, as 1) I'm not too fond of its user interface, and 2) it's a big pile of PHP, difficult to keep updated, and basically a disaster waiting to happen (and in fact, it was hacked at one point). Before I enable it again, is there any alternatives I should consider? Preferably written in Haskell, of course, but other suggestions welcome as well. -k -- If I haven't seen further, it is by standing in the footprints of giants

5 6

Re: [Haskell-cafe] a code that cannot compile with or without NoMonomorphismRestriction
by Denis Moskvin 30 Mar '12

30 Mar '12

f :: (Show a, Ord b) => (a -> String, b -> b -> Bool) f = let commond_definitions = undefined in let f1 = id.show f2 x = (< x) in (f1, f2) > From: Ting Lei <tinlyx(a)hotmail.com> > To: <haskell-cafe(a)haskell.org> > Cc: > Date: Wed, 28 Mar 2012 23:42:30 -0700 > Subject: [Haskell-cafe] a code that cannot compile with or without > NoMonomorphismRestriction > Hi > > I have met a piece of code that cannot be compiled whether I add or remove > the NoMonomorphismRestriction flag (as of GHC 7.0.4, Haskell platform > 2011.4.0.0). > I have extracted a minimal example below: > > > > {-# LANGUAGE NoMonomorphismRestriction #-} > (f1, f2) = > let commond_definitions = undefined in > let f1 = id.show > f2 x = (< x) > in > (f1, f2) > > I needed this format because there are many shared definitions in > common_definitions for f1 and f2, and I want to keep them local. > > If I compile them with NoMonomorphismRestriction, I get: > > D:\work\test.hs:7:8: > Ambiguous type variable `a0' in the constraint: > (Show a0) arising from a use of `f1' > Possible cause: the monomorphism restriction applied to the following: > f1 :: a0 -> String (bound at D:\work\hsOcaml\test.hs:2:2) > Probable fix: give these definition(s) an explicit type signature > In the expression: f1 > In the expression: (f1, f2) > In the expression: > let > f1 = id . show > f2 x = (< x) > in (f1, f2) > D:\work\test.hs:7:12: > Ambiguous type variable `a1' in the constraint: > (Ord a1) arising from a use of `f2' > Possible cause: the monomorphism restriction applied to the following: > f2 :: a1 -> a1 -> Bool (bound at D:\work\hsOcaml\test.hs:2:6) > Probable fix: give these definition(s) an explicit type signature > In the expression: f2 > In the expression: (f1, f2) > In the expression: > let > f1 = id . show > f2 x = (< x) > in (f1, f2) > Failed, modules loaded: none. > > If I comment out > -- {-# LANGUAGE NoMonomorphismRestriction #-} > I get: > > D:\work\hsOcaml\test.hs:4:17: > Ambiguous type variable `a0' in the constraint: > (Show a0) arising from a use of `show' > Possible cause: the monomorphism restriction applied to the following: > f1 :: a0 -> String (bound at D:\work\hsOcaml\test.hs:2:2) > Probable fix: give these definition(s) an explicit type signature > or use -XNoMonomorphismRestriction > In the second argument of `(.)', namely `show' > In the expression: id . show > In an equation for `f1': f1 = id . show > D:\work\hsOcaml\test.hs:7:12: > Ambiguous type variable `a1' in the constraint: > (Ord a1) arising from a use of `f2' > Possible cause: the monomorphism restriction applied to the following: > f2 :: a1 -> a1 -> Bool (bound at D:\work\hsOcaml\test.hs:2:6) > Probable fix: give these definition(s) an explicit type signature > or use -XNoMonomorphismRestriction > In the expression: f2 > In the expression: (f1, f2) > In the expression: > let > f1 = id . show > f2 x = (< x) > in (f1, f2) > Failed, modules loaded: none. > > Can anyone show me why this does not work and how to fix it (e.g. by > adding type signature as the error message suggested)? > I tried to add type signature by couldn't figure out the right way of > doing it. > > Thanks in advance! > > Ting Denis Moskvin

1 0

DHD >>= UHac: Register by April 1 for the DHD
by Sean Leather 30 Mar '12

30 Mar '12

DHD >>= UHac will be held from Friday, April 20, to Sunday, April 22, 2012. The Dutch HUG Day (DHD) is on the first day. The Utrecht Hackathon (UHac) follows the DHD on Friday and continues through the weekend. http://www.haskell.org/haskellwiki/DHD_UHac *Please register for the DHD by Sunday, April 1.* Our sponsor for the DHD, Ordina, will use the registration to prepare the (free!) lunch and venue. If you're coming only to UHac and not the DHD, you can register by April 19. http://www.haskell.org/haskellwiki/DHD_UHac/Register See you in Utrecht! The Organizers: Sean Leather Jurriën Stutterheim Jurriaan Hage

1 0

How helpful is h-99 (and should we complete the missing ones)?
by Ziyao Wei 29 Mar '12

29 Mar '12

Hi all, I am new at Haskell, but I am trying to learn as much as possible. While learning, I noticed that h-99 (the 99 Haskell problems) are highly recommended on haskell.org. However, the answers to the 99 problems are not finished, and some of the answers are not really Haskell-ish. So here's my question: how useful is h-99 (are they overrated as learning tools)? I find myself solve most of them in a "from the scratch" fashion (e.g., no Monad, no Applicative, no Functor aside from List and a few Maybe). Some of them are paper-worthy, for example the prime problems. I hope some guru-level Haskeller could do away the missing few, and maybe dive deeper into the surface to produce more insights (like the knights travel page or the sieve paper, which are both beautiful). And of course, if anyone could tell me how to learn Haskell without treating it as just another functional language, I'd be very grateful:) Thanks, Ziyao

1 0

winhugs interrupts
by Doug McIlroy 29 Mar '12

29 Mar '12

On windows I have long used hugs under cygwin, but hugs doesn't get along well with cygwin's latest terminal emulator. So I switched to winhugs. Small problem that looms big: how do you interrupt an interminable expression evaluation in winhugs? Doug

2 1

Re: [Haskell-cafe] adding the elements of two lists
by Doug McIlroy 29 Mar '12

29 Mar '12

> Date: Tue, 27 Mar 2012 11:03:54 +1300 > From: "Richard O'Keefe" <ok(a)cs.otago.ac.nz> > Subject: Re: [Haskell-cafe] adding the elements of two lists > To: <jerzy.karczmarczuk(a)unicaen.fr> > Cc: haskell-cafe(a)haskell.org > > And *that* is why I stopped trying to define instance Num t => Num [t]. > If "I KNEW that the length of the lists is ... fixed ..." then the type > wasn't *really* [t], but some abstract type that happened to be implemented > as [t], and that abstract type deserved a newtype name of its own. > > Naming the type > - makes the author's intent clearer to readers > - lets the compiler check it's used consistently > - lets you have instances that don't match instances for > other abstract types that happen to have the same implementation > - provides a natural place to document the purpose of the type > - gives you a way to enforce the intended restrictions > all for zero run-time overhead. Quite taken by this manifesto for high style and morality, I resolved to do right by some old code, of which I had been quite proud: www.cs.dartmouth.edu/~doug/powser.html. Sadly, the exercise took some bloom off the rose. What the code gained in honesty and safety, it lost in beauty and readability. Here's the contrast, seen in overloading arithmetic to handle addition and multiplication of power series. --------- without newtype toSeries f = f : repeat 0 -- coerce scalar to series instance Num a => Num [a] where (f:fs) + (g:gs) = f+g : fs+gs (f:fs') * gs@(g:gs') = f*g : fs'*gs + (toSeries f)*gs' --------- with newtype newtype Num a => PS a = PS [a] deriving (Show, Eq) fromPS (PS fs) = fs -- extract list toPS f = PS (f : repeat 0) -- coerce scalar to series instance Num a => Num (PS a) where (PS (f:fs)) + (PS (g:gs)) = PS (f+g : fs+gs) (PS (f:fs)) * gPS@(PS (g:gs)) = PS $ f*g : fromPS ((PS fs)*gPS + (toPS f)*(PS gs)) The code suffers a pox of PS. When one goes on to introduce efficiencies and generalize to handle finite series (polynomials), it only gets worse. One unpleasant technical problem: the deriving clause is almost useless--one can't print or detect equality of infinite objects. For output one must apply something like (take 10 . fromPS). Yet this modest package would likely pose problems if it were combined with others in a grander suite for automated mathematics. What to do? I think I might write the package without newtype, and then wrap it in PS for export in hopes of exploiting the advantages of both styles.

4 3

Mathematics and Statistics libraries
by Ben Jones 29 Mar '12

29 Mar '12

I am a student currently interested in participating in Google Summer of Code. I have a strong interest in Haskell, and a semester's worth of coding experience in the language. I am a mathematics and cs double major with only a semester left and I am looking for information regarding what the community is lacking as far as mathematics and statistics libraries are concerned. If there is enough interest I would like to put together a project with this. I understand that such libraries are probably low priority, but if anyone has anything I would love to hear it. Thanks for reading, -Benjamin

10 11

a code that cannot compile with or without NoMonomorphismRestriction
by Ting Lei 29 Mar '12

29 Mar '12

Hi I have met a piece of code that cannot be compiled whether I add or remove the NoMonomorphismRestriction flag (as of GHC 7.0.4, Haskell platform 2011.4.0.0).I have extracted a minimal example below: {-# LANGUAGE NoMonomorphismRestriction #-} (f1, f2) = let commond_definitions = undefined in let f1 = id.show f2 x = (< x) in (f1, f2) I needed this format because there are many shared definitions in common_definitions for f1 and f2, and I want to keep them local. If I compile them with NoMonomorphismRestriction, I get: D:\work\test.hs:7:8: Ambiguous type variable `a0' in the constraint: (Show a0) arising from a use of `f1' Possible cause: the monomorphism restriction applied to the following: f1 :: a0 -> String (bound at D:\work\hsOcaml\test.hs:2:2) Probable fix: give these definition(s) an explicit type signature In the expression: f1 In the expression: (f1, f2) In the expression: let f1 = id . show f2 x = (< x) in (f1, f2)D:\work\test.hs:7:12: Ambiguous type variable `a1' in the constraint: (Ord a1) arising from a use of `f2' Possible cause: the monomorphism restriction applied to the following: f2 :: a1 -> a1 -> Bool (bound at D:\work\hsOcaml\test.hs:2:6) Probable fix: give these definition(s) an explicit type signature In the expression: f2 In the expression: (f1, f2) In the expression: let f1 = id . show f2 x = (< x) in (f1, f2) Failed, modules loaded: none. If I comment out -- {-# LANGUAGE NoMonomorphismRestriction #-} I get: D:\work\hsOcaml\test.hs:4:17: Ambiguous type variable `a0' in the constraint: (Show a0) arising from a use of `show' Possible cause: the monomorphism restriction applied to the following: f1 :: a0 -> String (bound at D:\work\hsOcaml\test.hs:2:2) Probable fix: give these definition(s) an explicit type signature or use -XNoMonomorphismRestriction In the second argument of `(.)', namely `show' In the expression: id . show In an equation for `f1': f1 = id . showD:\work\hsOcaml\test.hs:7:12: Ambiguous type variable `a1' in the constraint: (Ord a1) arising from a use of `f2' Possible cause: the monomorphism restriction applied to the following: f2 :: a1 -> a1 -> Bool (bound at D:\work\hsOcaml\test.hs:2:6) Probable fix: give these definition(s) an explicit type signature or use -XNoMonomorphismRestriction In the expression: f2 In the expression: (f1, f2) In the expression: let f1 = id . show f2 x = (< x) in (f1, f2) Failed, modules loaded: none. Can anyone show me why this does not work and how to fix it (e.g. by adding type signature as the error message suggested)?I tried to add type signature by couldn't figure out the right way of doing it. Thanks in advance! Ting

4 4

Re: [Haskell-cafe] adding the elements of two lists
by Doug McIlroy 29 Mar '12

29 Mar '12

> From: "Richard O'Keefe" <ok(a)cs.otago.ac.nz> > Date: Thu, 29 Mar 2012 16:34:46 +1300 > > On 29/03/2012, at 3:08 PM, Doug McIlroy wrote: > > --------- without newtype > > > > toSeries f = f : repeat 0 -- coerce scalar to series > > > > instance Num a => Num [a] where > > (f:fs) + (g:gs) = f+g : fs+gs > > (f:fs') * gs@(g:gs') = f*g : fs'*gs + (toSeries f)*gs' > > > > --------- with newtype > > > > newtype Num a => PS a = PS [a] deriving (Show, Eq) > > > > fromPS (PS fs) = fs -- extract list > > toPS f = PS (f : repeat 0) -- coerce scalar to series > > > > instance Num a => Num (PS a) where > > (PS (f:fs)) + (PS (g:gs)) = PS (f+g : fs+gs) > > (PS (f:fs)) * gPS@(PS (g:gs)) = > > PS $ f*g : fromPS ((PS fs)*gPS + (toPS f)*(PS gs)) > > Try it again. > > newtype PS a = PS [a] deriving (Eq, Show) > > u f (PS x) = PS $ map f x > b f (PS x) (PS y) = PS $ zipWith f x y > to_ps x = PS (x : repeat 0) > > ps_product (f:fs) (g:gs) = whatever > > instance Num a => Num (PS a) > where > (+) = b (+) > (-) = b (-) > (*) = b ps_product > negate = u negate > abs = u abs > signum = u signum > fromInteger = to_ps . fromInteger > > I've avoided defining ps_product because I'm not sure what > it is supposed to do: the definition doesn't look commutative. You have given the Hadamard product--a construction with somewhat esoteric properties. The product I have in mind is the ordinary mathematical product that one meets in freshman calculus. The distributive law yields this symmetric formulation (f:fs) * (g:gs) = f*g : (toSeries f)*gs + fs*(toSeries g) + (0 : fs*gs) The version I gave is an optimization (which I learned from Jerzy). For more explanation see www.cs.dartmouth.edu/~doug/powser.html. I like the lifting functions b and u, but they don't get one very far. The product is where the PS pox begins to bite badly. I would welcome a perspicuous formulation of that using newtype. Incidentally, a more efficient way to write the symmetric product is (f:fs) * (g:gs) = f*g : zipWith (f*) gs + zipWith fs (*g) + (0 : fs*gs) toSeries and zipWith appear in the formulas because Haskell overloading won't let one use the multiplication symbol for both series*series and scalar*series. One might also invent a distinct operator for the purpose. Coercion with toSeries strikes me as the least jarring of these approaches. zipWith suffers from mixing levels of abstraction--it signifies not the idea of multiplication, but the algorithm. A new operator would suffer both from unfamiliarity and lack of commutativity. > > > The code suffers a pox of PS. > > But it doesn't *need* to. > >

1 0

adding the elements of two lists
by TP 29 Mar '12

29 Mar '12

Hello, My primary problem may be reduced to adding elements of two lists: [1,2,3] + [4,5,6] = [5,7,9] My first idea was to declare a list of Int as an instance of Num, and define (+) in the correct way. However, it seems it is not possible to do that: ------------------- instance Num [Int] where l1 + l2 = .... ------------------- Why? It seems it is necessary to do: ------------------ newtype ListOfInt = ListOfInt { getList :: [Int] } deriving (Show, Eq) instance Num ListOfInt where l1 + l2 = ... ------------------- Am I correct? Is it the best way to do that? Now, what is the most usual way to implement l1+l2? I have just read about applicative functors, with which I can do: ------------------- import Control.Applicative let l1 = [1,2,3] let l2 = [4,5,6] print $ getZipList $ (+) <$> ZipList l1 <*> ZipList l2 [5,7,9] ------------------- Is it the correct way to do that? I have tried: ------------------- instance Num ListOfInt where l1 + l2 = ListOfInt $ getZipList $ (+) <$> ZipList (getList l1) <*> ZipList (getList l2) ------------------- Isn't it too much complicated? Thanks TP

9 18