March 2007 - Haskell-Cafe

splitting strings
by h. 02 Mar '07

02 Mar '07

Hello, I wrote the following split function for Strings: splitS :: String -> String -> [String] splitS a b = splitA a b where z = length b - 1 splitA [] _ = [""] splitA (c:cs) (d:ds) | c == d && fst s == ds = "" : splitA (snd s) b | otherwise = (c : head r) : tail r where r = splitA cs b s = splitAt z cs example: splitS "Test;Hello;+123.5;+ 7" ";+" -> ["Test;Hallo","123.5"," 7"] How could it be optimized on speed? Does there exist already an optimized split for the conventional String type? -- Thanks in advance for your answer. h.

3 3

Using loop fusion for writing efficent high-level code Re[2]: [Haskell] [Fwd: Re: Computer Language Shootout]
by Bulat Ziganshin 02 Mar '07

02 Mar '07

Hello Duncan, Tuesday, February 27, 2007, 1:09:53 PM, you wrote: can you please provide examples of such code? the ultimate goal is to have tutorial on writing efficient code in high-level manner, but that is too ambitious. just some examples with a little explanation of how this is compiled? thanks in advance >> So I think we should do the same. It even shows in the Shootout - the >> programs that are simultaneously fastest and clearest are not pure >> Haskell, but delegate their innermost loops to tuned C libraries (FPS >> and GMP). > I should note that FPS is almost completely Haskell code, not C. We use > C for things like memcmp, memcpy, memset, reverse_copy, intersperse, > maximum, minimum and count. > Certainly some of the innards are low level style Haskell, though not > the kind that could be replicated in C because we use high level > transformations to fuse loop bodies together and wrap them in high > performance, low level loop code. > This is not the style where we just wrap well tuned C code, this is a > style where we generate high performance low level code from a high > level spec. This relies on GHC's excellent and programmable optimiser. > It's wrong to say that the shootout improvements were only down to > improved libraries. The performance of ByteString code improved very > significantly between GHC 6.4 and 6.6 and a large part of that was down > to optimiser improvements (not just the ForeignPtr rep change). Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 7

Re: [Haskell-cafe] Re: OO Design in Haskell
by P. R. Stanley 01 Mar '07

01 Mar '07

>Hi > >>forgive my ignorance but I thought functional programming was a >>mathematically sound framework unlike Object Oriented programming. > >Referentially transparent is a better term than mathematically sound >here. This is the property that x = y means that instances of x can be >replaced with y. >Could you elaborate please? >>Isn't using Haskell for OOP kind of defeating the whole object? > >It is defeating the point of expressing programs in a beautiful way, >but if you are building it on top of Haskell, without going to things >like unsafePerformIO, then you still end up with a referentially >transparent framework. I suppose one thing OO has going for it is a useful system of organising your code. Beyond that I'm afraid it is open to the same issues which plagued the soft eng world in the 70s. Yet, everyone seems to be mad about it inthe business. Sorry if this is going slightly off-topic. Paul

1 0

Build failed - hidden package ?
by Dunric 01 Mar '07

01 Mar '07

Hi. I've got stuck with the following compilation error I probably can't fully understand: ---------------------------------------------------------------------- Building library... ... Using package config file: /usr/local/lib/ghc-6.6/package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static ... Graphics/UI/SDL/Rotozoomer.hs:15:7: Could not find module `Foreign.C': it is a member of package base, which is hidden ---------------------------------------------------------------------- What does such error mean ? Modules Foreign and Foreign.C are installed and available from the default path. Lines 12-15 of Rotozoomer.hs: ------------------------------------------ module Graphics.UI.SDL.Rotozoomer where import Foreign import Foreign.C ------------------------------------------ Any idea what's wrong, resp. some explanation why compilation fails ? Thanks in an advance. ------------------------------------------ www.icqsms.cz

2 1

Re: [Haskell-cafe] Re: OO Design in Haskell Example (Draft)
by Tim Docker 01 Mar '07

01 Mar '07

"Steve Downey" <sdowney(a)gmail.com> wrote: > I'm not sure, though, what would happen if I tried to > add state to the types. With the previous example, > using existentials to create a reference type that > holds elements of a type class that matches the interface, > I think that it would be natural to hold state by having > that element stored in a mutable state variable, and replacing > the held values. State is often best avoided, but if it's really what you want to do, you can still capture a mutable variable in the closures captured inside the record of functions. Tim import Data.IORef data Component = Component { draw :: IO (), move :: (Int,Int) -> IO () } newCircle :: IO Component newCircle = do pref <- newIORef (0,0) return Component{draw=draw' pref, move=move' pref} where draw' pref = do p <- readIORef pref putStrLn ("circle at " ++ show p) move' pref p = writeIORef pref p

3 2

Whatever happened to Trex.hs
by Adam Wyner 01 Mar '07

01 Mar '07

Hi, I'd been using trex.hs for extensible records and programmed a bit using it. I liked it for what it did and also because it had very nice documentation on how to use it. I know there are other proposals and implementations in Haskell for records (HaskellDB and HList), but for the time being I still want to use Trex.hs. It seems to me that the current distribution of Haskell is not supporting Trex, or at least I can't find any information anymore about it, nor anything on the discussion lists. Installing recent distributions of Hugs gives me error messages about missing type constructors for records. Thanks, Adam

1 0

Automatic Recognition of Functors
by Walter Potter 01 Mar '07

01 Mar '07

Folks, Given f:: a -> b it is very natural to lift f to P f :: P a -> P b where P is the power set functor. Or L f :: [a] -> [b]. We are modeling structures using repeated application of the power functor, via repeated application of [ ]. It would be very nice if Haskell would recognize this lifting. That is, if f :: a -> b then one automatically has f :: [a] -> [b] without using fMap. We can do something similar with classes in the following way: Given class Addy a where (+.) :: a -> a -> a instance(Addy a) => Addy [ a] (+.) w [ ] = w (+.) [ ] w = w (+.) (a:as) (b:bs) = (a+b) :(as + bs) Now given instance Addy Int (+.) x y = x+y One can compute [[1,2],[3,4]] +. [ [2,3],[1,2,.3]]. I know I'm asking for a bit more here. I might need to use fMap f : [ a] -> [ b]. But I can't seem to get by with fMap f [[1,2],[3,4]] when f :: Int -> Int We often need to lift functions to higher power maps. It would be nice to have a way to do this with ease. Suggestions are welcome. Walt

3 2

Re: [Haskell-cafe] numeric minimization in Haskell
by Chad Scherrer 01 Mar '07

01 Mar '07

David Roundy wrote: > It seems like GSLHaskell is an awfully big stick, when all you need are > scalar multiply and vector addition. Of course, we don't know what > functions he wants to minimize, but in the absence of any need for GSL > functions, I don't see a good reason for it. The function is just a linear combination of sines and cosines. No need for GSL for that. > I see that GSLHaskell has a binding to a conjugate gradients minimizer, but > it's not useful for any hard problems (it stores the trajectory, which > defeats the purpose of using conjugate gradients), and can only be very, > very slow. I had been throwing the trajectory away without any more thought, but I suppose it would slow things down quite a bit. > >From the API alone it cannot be efficient. Code that is written by people > who obviously either don't know or don't care about efficiency is just not > in general a good idea. I don't know what you use GSLHaskell for in your > work, but I hope you don't use it for conjugate gradients, or only use it > on easy problems. I agree, given the API it seems like it could be very nice for visualizing how CG works, but it does seem to rule out high performance. > -- > David Roundy > Department of Physics > Oregon State University Chad Scherrer

1 0

Blog post: 'Haskell IO for imperative programmers'
by David House 01 Mar '07

01 Mar '07

It's not mine, but I just came across the following from a link in #haskell: http://blogs.nubgames.com/code/?p=22 A brilliantly written, fantastically clear exposition of IO from the point of view of a long-time imperative programmer. Don't miss it. One to forward to friends and coworkers. -- -David House, dmhouse(a)gmail.com

1 0

OO Design in Haskell Example (Draft)
by Steve Downey 01 Mar '07

01 Mar '07

In the last OO design in Haskell thread (and probably in every one preceeding it), it was suggested that having some examples might be a good idea. Since most people with existing designs will have some familiarity with Design Patterns, and those are typical building blocks for OO designs, it occured to me that implementing some of them might be a useful excersize. If for nothing other than learning some more Haskell. Now, some of them are probably bad ideas for implementing in Haskell. There's a better, or more natural, way than what is suggested by the design pattern. Visitor is probably not a good pattern to follow, for example. On the other hand, others may still be useful, even in a functional language. So, I've been working on a Composite example. I've used existential types to have a generic proxy to the base type, rather than a simple algebraic type, since adding new leaves to the algebraic type means modifying the whole type, a violation of the Open-Closed principle (open for extension, closed for modification) The interface of the composite. Two methods, add and draw. > class IComponent e where > draw ::e -> String > add :: (IComponent e') => e -> e' -> Component A proxy type which can hold any kind of component, and provides the 'virtual' dispatch implementation. That is, it forwards to the add or draw implementation of the instance it is proxying for. > data Component = > forall e.(IComponent e) => Component e > componentDraw :: Component -> String > componentDraw (Component c) = draw c > componentAdd :: (IComponent e) => Component -> e -> Component > componentAdd (Component e) a = Component (add e a) > instance IComponent Component where > draw = componentDraw > add = componentAdd The Single type, which is the leaf node in this composite, add is a no-op, except for wrapping the value in a Component. Since there isn't an implicit down cast from the 'derived' Single to the 'base' Component. > data Leaf = > Text String > deriving(Show, Eq) > leafDraw :: Leaf -> String > leafDraw (Text s) = show s > leafAdd :: (IComponent e) => Leaf -> e -> Component > leafAdd s _ = Component s > instance IComponent Leaf where > draw = leafDraw > add = leafAdd The Composite type, which holds a list of Components through the composite proxy. I was tempted to make the list a state variable, so that add could modify rather than produce a new Many, but I wanted to get the basics working. > data Composite = > Many [Component] > compositeDraw :: Composite -> String > compositeDraw (Many []) = "()" > compositeDraw (Many leaves) = "(" ++ (foldr1 (++) $ map draw leaves) ++ ")" > compositeAdd :: (IComponent e) => Composite -> e -> Component > compositeAdd (Many leaves) c = > Component $ Many ((Component c) : leaves) > instance IComponent Composite where > draw = compositeDraw > add = compositeAdd >

5 6