March 2010 - Haskell-Cafe

Fwd: [Haskell-cafe] Bytestrings and [Char]
by Alberto G. Corona 18 Jul '10

18 Jul '10

The question can be generalized via type classes: Is there any common set of primitives encapsulated into a single type class that has instances for Strings (Data.List) ByteStrings, Data.Text, Lazy bytestrings, Arrays, vectors and wathever container that can store an boxed, unboxed, packed unpacked sequence of wathever including chars? All of them have folds, heads, tails and a lot of common functions with the same name, but since there is not a single type class, the library programmer can not abstract his code when it is possible, so the library user can chose the particular instance for his particular problem. 2010/3/23 Johann Höchtl <johann.hoechtl(a)gmail.com> On 22.03.2010 14:15, Ivan Miljenovic wrote: > >> On 23 March 2010 00:10, Johan Tibell<johan.tibell(a)gmail.com> wrote: >> >> >>> A sequence of bytes is not the same thing as a sequence of Unicode >>> code points. If you want to replace String by something more efficient >>> have a look at Data.Text. >>> >>> >> Though Data.Text still has the disadvantage of not being as nice to >> deal with as String, since you can't pattern match on it, etc. >> >> Whilst it may degrade performance, treating String as a list of >> characters rather than an array provides you with greater flexibility >> of how to deal with it. >> >> >> > But doesn't this basically mean sacrifice performance / applicability for > algorithmic beauty? Sure, pattern match comes in handy, but in the case of > strings at a high price > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 3

haskell platform questions
by Warren Harris 12 Jul '10

12 Jul '10

I installed haskell platform some time ago, and now I'm wondering what version I have. How do I find out? Also, when the new one comes along on the 21st, is there a way to upgrade? Or if I must first uninstall the one I have now, how do I uninstall it? Is it recommended to periodically upgrade packages that came with the platform (cabal upgrade), or is it recommended that they be left alone to avoid dependency incompatibilities. Similar question for ghc itself -- can/should it be upgraded in the context of haskell platform? (I was hoping to try Leksah, but it dies without ghc 6.12.1. I seem to have 6.10.4.) Apologies in advance if this is all documented somewhere, but I couldn't find it on the haskell platform site/trac. BTW, I'm on Mac/ Leopard -- love the fact that it didn't take hours to build everything! Warren

9 22

ANN: ForSyDe DSL v3.1
by Seyed Hosein Attarzadeh Niaki 25 Jun '10

25 Jun '10

Dear All, A new version of the ForSyDe DSL is uploaded to the Hackage database. "The ForSyDe (Formal System Design) methodology has been developed with the objective to move system design to a higher level of abstraction and to bridge the abstraction gap by transformational design refinement. This library provides ForSyDe's implementation as a Haskell-embedded Domain Specific Language (DSL). For more information, please see ForSyDe's website: http://www.ict.kth.se/forsyde/." In addition to compatibility with base 4 and GHC 6.10.x, the new version provides more freedom for declaration of process functions (e.g., support for when and let blocks). BR/ Hosein Attarzadeh

1 1

ANN: parameterized-data library v0.1.4
by Seyed Hosein Attarzadeh Niaki 25 Jun '10

25 Jun '10

Dear Haskell developers, A new version of the parameterized-data library providing fixed-sized vectors (based on the type-level library) is pushed into the repository and uploaded to the Hackage database. This is only a minor update to fix the compatibility issues with base 4, GHC>=6.10 and cabal-install (not backward compatible). Bests, Hosein Attarzadeh

1 1

Help with Bird problem 3.3.3
by Peter Hilal 11 Jun '10

11 Jun '10

I'm working my way through Bird's _Introduction to Functional Programming Using Haskell_. I'd appreciate any help with problem 3.3.3, which is: "Division of natural numbers can be specified by the condition (n * m) / n = m for all positive n and all m. Construct a program for division and prove that it meets the specification." The required construction relies on the following definitions: data Nat = Zero| Succ Nat (+) :: Nat -> Nat m + Zero = m m + Succ n = Succ (m + n) (*) :: Nat -> Nat m * Zero = Zero m * Succ n = m * n + m Proceeding as Bird does in Sec. 3.2.2, where he derives the definition of "-" from the specification "(m + n) - n = m", I've so far gotten the first case, in which m matches the pattern "Zero", simply by (i) substituting Zero for m in the specification, (ii) substituting Succ n for n in the specification (solely because n is constrained to be positive), and (iii) reducing by applying the first equation of "*": Case Zero: (Succ n * Zero) / Succ n = Zero ≡ {first equation of "*"} Zero / Succ n = Zero Easy enough, and completely intuitive, since we expect Zero divided by any non-Zero finite number to be Zero. The next case, in which m matches the pattern "Succ m", is where I get stuck, and I really have no intuition about what the definition is supposed to be. My first step is to substitute "Succ m" for "m" in the given specification, and to substitute Succ n for n in the specification (for the same reason, as above, that n is constrained to be positive), and then to use the definition of "*" to reduce the equation: Case Succ m: Succ n * Succ m / Succ n = Succ m ≡ {second equation of "*"} (Succ n * m + Succ n) / Succ n = Succ m Where do I go from here? Thank you so much.

5 4

GHC 6.12 on OS X 10.5
by Conor McBride 08 May '10

08 May '10

Hi I thought I'd record my upgrade exerience (so far) in case anyone else finds it useful, and (more selfishly) in case anyone has some helpful advice. Summary of situation * I got 6.12 working. * It took a lot of fumbling around. * The eventual "fix" (renaming /opt/local/lib/libiconv.dylib) was a bit dodgy, but is holding for now. Long rambling narrative follows. Various features of GHC 6.12 made it very tempting to go for an earlier upgrade than I normally would. (SHE really needs GADT-style data families; everything I do needs deriving Traversable (deriving HalfZip would be nice too!).) Already there was a handy installer for Intel+Leopard macs (is anybody on the PPC+Leopard case? if not, I will be soon...). I thought "go for it". Installation, no problem. Compiling something: whoops, no mtl. OK, cabal install mtl: whoops, no acceptable cabal. Fair dos, if I'd read the warnings I'd have known that my cabal-install would be useless and tried to build the new one. QUESTION: Is the sensible upgrade path to build cabal-install 0.8 with your old GHC, before installing 6.12? Does this even work? At one point, I tried this and had some peculiar issues involving zlib... Anyhow, I've got 6.12 and I need cabal-install 0.8. Can I find it? Tricky, and http://haskell.org/cabal/ didn't help much. I'm very tolerant of busy people not quite getting round to it, and I can use google, so I find the darcs version and get cracking. This happens: ----------------------------------------------------------------------------- bash-3.2$ ./bootstrap.sh Checking installed packages for ghc-6.12.1... parsec-2.1.0.1 will be downloaded and installed. network-2.2.1.5 will be downloaded and installed. Cabal is already installed and the version is ok. mtl-1.1.0.2 will be downloaded and installed. HTTP-4000.0.8 will be downloaded and installed. zlib-0.5.2.0 will be downloaded and installed. Downloading parsec-2.1.0.1... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 15430 100 15430 0 0 12743 0 0:00:01 0:00:01 --:--:-- 19312 [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status Error during cabal-install bootstrap: Compiling the Setup script failed ----------------------------------------------------------------------------- At lthis point, I suspected a linker/dylib problem, but foolishly, I wanted the problem to be pretty much anything else, so I spent far too long looking the wrong way. I thought that if I could just get cabal-install working somehow, I'd be ok. I tried installing parsec with runhaskell Setup.hs {configure,build,install} but each of these commands appeared content to do precisely nothing: I found this perplexing. I tried reverting to 6.10.4 and compiling cabal-install. This made more progress, but died with some sort of zlib version snafu. (I'm sorry, I should have recorded the details but didn't.) The zlib-0.5.2.0 package did install successfully, but somehow the build for cabal-install itself went awry with an "even though this is the right version I can't find X" sort of a problem. I uninstalled 6.10.4, deleted my .cabal directory, nuked a few other relics showing up from what's probably a dumb choice of PATH setting. I had another go at 6.12, and this time I tried compiling a wee program of my own with no exciting package dependencies. Should have done that straight away, of course. Same iconv problem. This left no alternative. I found I had a /usr/lib/libiconv.dylib etc and an /opt/local/lib/libiconv.dylib etc, so I renamed the latter to opt/local/lib/moolibiconv.dylib, and suddenly, GHC became capable of linking stuff. The darcs version of cabal-install then built just fine; SHE rebuilt ok; Epigram needed a few extra LANGUAGE pragmas, but no trouble. I'm almost back where I was. I worry about this. (1) What have I broken by shifting the opt/local/lib copy of libiconv? (2) Why did that break things anyway? (3) How come I ended up with a broken library setup? (4) What else is broken? (What's worse than finding a maggot in your apple? Finding half a maggot in your apple.) I'm not at all a mac expert (I use a mac because I'm too stupid to maintain a linux installation -- the Nottingham grad students (all grown up now) told me they were fed up fixing my computer back in 04.) This dylib nonsense seems quite common. Is it MacPorts messing things up? Is there a more principled fix than the brutal thing I did? I wonder if it might be possible to build some sort of diagnostic tool to check paths and libraries for conflicts and omissions. Anyhow, sorry for the dreariness of this story, but it ends in an acceptable configuration, for the moment. I hope it can be of some small help. Happy hols Conor

10 19

accents
by Dupont Corentin 07 May '10

07 May '10

Hello, i have a list of french words with accents. How could i handle them? If i load them with ghci i get: > a <- readFile "list.txt" > head $ lines a "abn\233gation" putStrLn displays a strange character for the "é". Cheers, Corentin

3 4

Asynchronous exception wormholes kill modularity
by Bas van Dijk 01 May '10

01 May '10

Dear all, (sorry for this long mail) When programming in the IO monad you have to be careful about asynchronous exceptions. These nasty little worms can be thrown to you at any point in your IO computation. You have to be extra careful when doing, what must be, an atomic transaction like: do old <- takeMVar m new <- f old `onException` putMVar m old putMVar m new If an asynchronous exception is thrown to you right after you have taken your MVar the putMVar will not be executed anymore and will leave your MVar in the empty state. This can possibly lead to dead-lock. The standard solution for this is to use a function like modifyMVar_: modifyMVar_ :: MVar a -> (a -> IO a) -> IO () modifyMVar_ m io = block $ do a <- takeMVar m a' <- unblock (io a) `onException` putMVar m a putMVar m a' As you can see this will first block asynchronous exceptions before taking the MVar. It is usually better to be in the blocked state as short as possible to ensure that asynchronous exceptions can be handled as soon as possible. This is why modifyMVar_ unblocks the the inner (io a). However now comes the problem I would like to talk about. What if I want to use modifyMVar_ as part of a bigger atomic transaction. As in: block $ do ... modifyMVar_ m f ... >From a quick glanse at this code it looks like asynchronous exceptions can't be thrown to this transaction because we block them. However the unblock in modifyMVar_ opens an asynchronous exception "wormhole" right into our blocked computation. This destroys modularity. Besides modifyMVar_ the following functions suffer the same problem: * Control.Exception.finally/bracket/bracketOnError * Control.Concurrent.MVar.withMVar/modifyMVar_/modifyMVar * Foreign.Marshal.Pool.withPool We can solve it by introducing two handy functions 'blockedApply' and 'blockedApply2' and wrapping each of the operations in them: > import Control.Exception > import Control.Concurrent.MVar > import Foreign.Marshal.Pool > import GHC.IO ( catchAny ) > blockedApply :: IO a -> (IO a -> IO b) -> IO b > blockedApply a f = do > b <- blocked > if b > then f a > else block $ f $ unblock a > blockedApply2 :: (c -> IO a) -> ((c -> IO a) -> IO b) -> IO b > blockedApply2 g f = do > b <- blocked > if b > then f g > else block $ f $ unblock . g Control.Exception: > finally :: IO a -> IO b -> IO a > a `finally` sequel = blockedApply a $ \a' -> do > r <- a' `onException` sequel > _ <- sequel > return r > bracket :: IO a-> (a -> IO b) -> (a -> IO c) -> IO c > bracket before after thing = blockedApply2 thing $ \thing' -> do > a <- before > r <- thing' a `onException` after a > _ <- after a > return r > bracketOnError :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c > bracketOnError before after thing = blockedApply2 thing $ \thing' -> do > a <- before > thing' a `onException` after a Control.Concurrent.MVar: > withMVar :: MVar a -> (a -> IO b) -> IO b > withMVar m io = blockedApply2 io $ \io' -> do > a <- takeMVar m > b <- io' a `onException` putMVar m a > putMVar m a > return b > modifyMVar_ :: MVar a -> (a -> IO a) -> IO () > modifyMVar_ m io = blockedApply2 io $ \io' -> do > a <- takeMVar m > a' <- io' a `onException` putMVar m a > putMVar m a' > modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b > modifyMVar m io = blockedApply2 io $ \io' -> do > a <- takeMVar m > (a',b) <- io' a `onException` putMVar m a > putMVar m a' > return b Foreign.Marshal.Pool: > withPool :: (Pool -> IO b) -> IO b > withPool act = blockedApply2 act $ \act' -> do > pool <- newPool > val <- catchAny > (act' pool) > (\e -> do freePool pool; throw e) > freePool pool > return val I'm not proposing to make this change (yet) because I first would like to have some discussion on this. Thanks for reading this rather long mail, Bas

13 46

Hughes' parallel annotations for fixing a space leak
by Heinrich Apfelmus 22 Apr '10

22 Apr '10

Dear haskell-cafe, I've been thinking about space leaks lately. In particular, I've been studying the tricky example with pairs break [] = ([],[]) break (x:xs) = if x == '\n' then ([],xs) else (x:ys,zs) where (ys,zs) = break xs which was discussed in the papers Jan Sparud. Fixing some space leaks without a garbage collector. http://bit.ly/cOxcVJ Philip Wadler. Fixing some space leaks with a garbage collector. http://homepages.inf.ed.ac.uk/wadler/topics/garbage-collection.html As I understand it, GHC implements the technique from Sparud's paper, so this is a solved problem. (It will only kick in when compiled with optimization, though, so -O0 will make the above leak in GHC 6.10.4 if I checked that correctly.) Now, I'm wondering about alternative solutions. Wadler mentions some sort of parallel combinators break xs = (PAR before '\n' ys, PAR after '\n' zs) where (ys,zs) = SYNCLIST xs which were introduced by John Hughes in his Phd thesis from 1983. They are intriguing! Unfortunately, I haven't been able to procure a copy of Hughes' thesis, either electronic or in paper. :( Can anyone help? Are there any other resources about this parallel approach? Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

3 4

DLL on Windows
by Serguey Zefirov 20 Apr '10

20 Apr '10

I tried the way described in http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html and i got this error message: -------------------------------------------------------------------------------------------- ghc -shared -o test.dll --make test.hs [1 of 1] Compiling Test ( test.hs, test.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-mingw32): link: GHC not built to link this way: LinkDynLib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -------------------------------------------------------------------------------------------- How can I fix it?

7 17