- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] example of FFI FunPtr
by Galchin, Vasili 07 Jun '08

07 Jun '08

Hi Claude, I want to do an incremental "experiment". I want just want to pass a C function to "callback" to a Haskell function. ??? Thanks, Vasili On Thu, Jun 5, 2008 at 4:21 AM, Claude Heiland-Allen < claudiusmaximus(a)goto10.org> wrote: > Galchin, Vasili wrote: > >> Hello, >> >> I want to model a Haskell function that is a callback from C. I have >> only found one example in the unix package's Semaphore.hsc, which >> apparently >> is not used. I want to be able to marshall a Haskell function that is a >> first class citizen residing in a Haskell data type and pass to a C >> function >> via FFI. Are there examples of this? >> > > Attached is a simple example. > > The main thing to note is 'foreign import ccall "wrapper"' which gives you > a factory for turning Haskell functions into foreign function pointers. > > More information: > > http://www.cse.unsw.edu.au/~chak/haskell/ffi/<http://www.cse.unsw.edu.au/%7Echak/haskell/ffi/> > > > Claude > -- > http://claudiusmaximus.goto10.org > > > CallBacker: CallBacker.hs callerback.c callerback.h > ghc -O2 -Wall -fffi -o CallBacker CallBacker.hs callerback.c > >

2 1

Patrick Perry's BLAS package
by Andrzej Jaworski 07 Jun '08

07 Jun '08

Hi, Indeed, this has been long awaited. Long live Patrick!!! And continue the good work:-) However, such essential work shouldn't be dependent on heroic effort of an individual. If Haskell is to remain non-commercial a disciplined community effort should be taken akin to Pythonian. Perhaps also thouse of you who teach Haskell could better use cheap labour of students, after all Haskell's module system is not all that weak;-) Cheers, -A.J.

2 2

Dynamic curiosity
by Gökhan San 07 Jun '08

07 Jun '08

Hello All, I've recently modified my existing project to support dynamic data (using 'Data.Dynamic'), and despite my earlier benchmarks on 'Dynamic', the program slowed down by a factor of 10. Profiler says that 'fromDynamic' is consuming 60% of the CPU time (with -O2). Using the below function instead of 'fromDynamic' seems to make coercion 20 times faster (thereby solving my problem): > {-# OPTIONS -fglasgow-exts #-} > import GHC.Prim > data Dynamic' = Dynamic' TypeRep Any > fromDynamic' :: forall a. Typeable a => Dynamic -> Maybe a > fromDynamic' d = > let Dynamic' t v = unsafeCoerce# d > in if t == typeOf (undefined :: a) > then Just (unsafeCoerce# v) > else Nothing I was able to reproduce the same result from scratch. The only difference with the standard implementation (I put it below for reference), other than the first ugly unsafeCoerce#, seems to be existential quantification (i.e. When I replace "if t == typeOf (undefined :: a) ..." with the "case ..." below, performance goes down again.). > fromDynamic :: Typeable a => Dynamic -> Maybe a > fromDynamic (Dynamic t v) = > case unsafeCoerce v of > r | t == typeOf r -> Just r > | otherwise -> Nothing So what is causing the improvement, or am I missing something? Thanks. -- Gokhan

1 0

Teaching Monads
by Ronald Guida 07 Jun '08

07 Jun '08

Monads in Haskell are a topic that I, like most beginners, find difficult and "mind-twisting". Now that I think I understand monads, they seem to be very simple; I've read that this is a common experience. So I wonder, what would it take to help beginners catch on with a minimum of fuss or frustration? The plethora of monad tutorials out there is clear evidence that plenty of others have wondered the same thing. What made monads "click" for me is when I understood the following things: 1. When monads are being used, closures are almost always involved. 2. These closures naturally arise when desugaring do-syntax. do x1 <- m1 m1 >>= (\x1 -> x2 <- m2 m2 >>= (\x2 -> [Eq1] x3 <- m3 m3 >>= (\x3 -> return (f x1 x2 x3) return (f x1 x2 x3)))) 3. These closures are extremely similar to the closures that arise when desugaring let-syntax. let x1 = f1 in f1 -$ (\x1 -> Where: let x2 = f2 in f2 -$ (\x2 -> (-$) :: a -> (a -> b) -> b let x3 = f3 in f3 -$ (\x3 -> x -$ f = f x f x1 x2 x3 f x1 x2 x3))) 4. While I can think of a monad as a fancy container that holds an element of type "t", it might be more accurate to think of a monad as a container that merely displays the type "t" as a label for its contents. The container might hold one object of type "t", or it might hold several. It might not be holding any at all. Perhaps the container /never/ holds an object of type "t", but instead it holds a set of instructions to produce such an object. (e.g. Reader, State). Naturally, it's hard to illustrate nested closures, higher-order functions, and objects that aren't really there. It's easy to illustrate a sequential scheme where a single "thing" passes through a series of operations, while some related data travels in parallel. m1 >>= f1 >>= f2 >>= f3 [Eq2] In any case, the extreme similarity between desugared "do" and desugared "let" leads me to think of the concepts of a manual plumbing system and a monadic plumbing system. Basically, a manual plumbing system is what I have if I'm threading information down through a series of nested function calls in a certain stereotypical way. A monadic plumbing system is what I get when I introduce the appropriate monad to encapsulate my threading. In fact, if I look at Wadler [*], there are three examples of an evaluator that use what I'm calling "manual plumbing". In section 2.5, the operations required of a monad (return, bind) pretty much just drop right out. Wadler even points out the similarity between "bind" and "let". Now that I finally "get it", I feel that the Wadler paper, section 2.5 in particular, is probably a better introduction than many of the monad tutorials out there. Moreover, I feel that for /some/ of the tutorials out there, they spend too much time and too many illustrations explaining things like [Eq2], and then they quickly present do-notation and gloss over [Eq1]. For me, I found that that the concepts of "manual plumbing" and "monadic plumbing" were key to actually grasping the Wadler paper and understanding what monads are. In particular, I feel that these two concepts might be a way to help other beginners catch on as well. OK, so before I attempt to write a monad tutorial based on "manual plumbing" and "monadic plumbing", I would like to know, does anyone else think this is a good idea? [*] "Monads for Functional Programming". (http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf)

4 3

ANNOUNCE: Cabal-1.4 release candidate
by Duncan Coutts 07 Jun '08

07 Jun '08

Hi everyone, == Cabal-1.4 release candidate == The second release candidate of Cabal-1.4 is out: http://haskell.org/cabal/download.html Please test and report bugs: http://hackage.haskell.org/trac/hackage/ The aim for the Cabal-1.4 release is to get various fixes and improvements into the hands of developers and to support a release of cabal-install. == cabal-install == A snapshot of cabal-install is also available: http://haskell.org/cabal/download.html It requires the zlib and HTTP packages (both are available from hackage). Bug reports should go in the same trac as above. cabal-install is intended to be the standard command line interface to the whole Cabal/Hackage system. It replaces the "runhaskell Setup.hs" interface and a few other tools you may or may not have heard of (cabal-setup, cabal-upload, cabal-get). cabal-install is usable now and we will be making a proper release some time after the Cabal-1.4 release. == Testing == We are particularly interested in finding regressions from Cabal-1.2.x or any important fixes that will require API changes since once we release 1.4 we have to maintain API compatibility for the rest of the 1.4.x series. This is also an excellent opportunity to make sure your favourite bug or feature request is properly described in our bug tracker: http://hackage.haskell.org/trac/hackage/ To help us guide development priorities please add yourself to the ticket's cc list and describe why that bug or feature is important to you. == Compatibility == We have tried to preserve compatibility with all packages that worked with the Cabal-1.2.x series. That is, packages that can be built using Cabal (including custom Setup.hs scripts) but not packages that directly import and use the Cabal API. Packages that directly import and use the Cabal api will need updating. This affects packages that build distro packages for example, rpm debs etc. Currently we know of only one package on hackage which has a Setup.hs script that compiles with 1.2 but fail to compile with 1.4. Takusen, will require an update to be able to work with both Cabal-1.2.x and 1.4.x. A patch has been sent to the maintainers of Takusen. == Credits == On behalf of the Cabal hackers and the community generally I'd like to thank the large number of people who have contributed patches during this development series. Previously I was rather worried that we were not getting enough contributors to fix bugs and do new feature development, but now I'm very pleased. :-) == Get involved == Of course there's still a lot to do! We have big plans for Cabal-2.0, cabal-install and the Hackage website. So if you're interested in helping out with this core infrastructure project then: * subscribe to the cabal-devel mailing list: http://www.haskell.org/mailman/listinfo/cabal-devel * grab the source: http://haskell.org/cabal/code.html * read the guide to the source code: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide * take a look at our list of bugs and feature requests: http://hackage.haskell.org/trac/hackage/report/12 especially the easy tickets: http://hackage.haskell.org/trac/hackage/report/13 Duncan (wearing his Cabal release manager hat)

2 1

installing happy 1.17
by Thomas Hartman 07 Jun '08

07 Jun '08

I had a problem installing happy 1.17 (same result with happy head). This appears to be required for installing happs-hsp-template via cabal install. thanks for any advice! Thomas. ***** thartman@thartman-laptop:~/haskellInstalls/smallInstalls>darcs get --partial http://darcs.haskell.org/happy/ ********************** Copying patch 87 of 87... done. Applying patch 86 of 86... done. Finished getting. thartman@thartman-laptop:~/haskellInstalls/smallInstalls>cd happy thartman@thartman-laptop:~/haskellInstalls/smallInstalls/happy>runghc Setup.lhs configure Setup.lhs:30:43: Not in scope: `buildVerbose' thartman@thartman-laptop:~/haskellInstalls/smallInstalls/happy>cabal --version cabal-install version 0.4.9 using version 1.3.12 of the Cabal library thartman@thartman-laptop:~/haskellInstalls/smallInstalls/happy>ghc-pkg list | grep -i cabal Cabal-1.2.3.0, Cabal-1.3.11, Cabal-1.3.12, Cabal-1.5.2,

1 0

Question about kinds
by Klaus Ostermann 07 Jun '08

07 Jun '08

Why does the code below not pass the type checker? If I could explictly parameterize y with the type constructor Id (as e.g. in System F), then 'y Id' should have the type Int -> Int and hence "y Id x" should be OK, but with Haskell's implicit type parameters it does not work. So, how can I make this work? Klaus ------------ type Id a = a x :: Id Int x = undefined y :: (a Int) -> (a Int) y = undefined test = y x Error: Couldn't match expected type `a Int' against inferred type `Id Int' In the first argument of `y', namely `x' In the expression: y x In the definition of `test': test = y x -- View this message in context: http://www.nabble.com/Question-about-kinds-tp17701553p17701553.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

6 5

What is the maturity of Haskell Web Frameworks
by Aditya Siram 06 Jun '08

06 Jun '08

I am building a web-app that, in broad strokes, allows a leader to assign tasks to team members and allows team members to accept/reject/pick tasks that they want to do. I really like Haskell and I would like to use it to implement the solution. Are frameworks like Happs ready? Not so much in terms of documentation, but in functionality and stability. -Deech _________________________________________________________________ Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?souce=EML_WL_ GoodCause

15 20

Analysing music
by Achim Schneider 06 Jun '08

06 Jun '08

The recent discussion about Markoff chains inspired me to try to train one with all the Bach midi's I have on my disk, collecting statistics on what intervals tend to get played simultaneously, which follow others and in which way the pitch offsets from its mean, so that melodies fall and raise "naturally". The rationale is that if it's Bach, it's harmonious but not respecting any kind of usual chord progression. So far, I got (a bit confused around the edges): getMid mf = do mid <- MidiLoad.fromFile mf return $ MidiRead.retrieveTracks mid toMelody :: MidiMusic.T -> StdMelody.T toMelody = Music.mapNote f where f note = let body = MidiMusic.body note in Melody.Note StdMelody.na (MidiMusic.pitch body) main = do args <- Env.getArgs let mf:[] = args m <- getMid mf putStr $ Format.prettyMelody $ Optimise.all $ Music.chord $ map (\m -> Music.line $ map toMelody m) m which results in chord [e 3 bn na, chord [b 2 wn na, line [hnr, d 3 wn na, hnr, cs 3 hn na, a 2 hn na, chord [cs 3 hn na, line [b 2 hn na, c 3 hn na]]]]] , for a set of random clicks in rosegarden's matrix editor. Right now, I'm desperately searching for functions that can help me analyse this beast, which afaict right now works best by having a multitude of transformations (e.g. one big top-level chord with maximum polyphony and a hell a lot of rests) that provide easy access to whatever information is needed. Does anyone of you know about previous work in this area? I don't want to break cultural imperatives by not being as lazy as possible. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.

6 7

How would you hack it?
by Andrew Coppin 06 Jun '08

06 Jun '08

So anyway, today I found myself wanting to build a program that generates some test data. I managed to make it *work* without too much difficulty, but it wasn't exactly "elegant". I'm curios to know how higher-order minds would approach this problem. It's not an especially "hard" problem, and I'm sure there are several good solutions possible. I have a file that contains several thousand words, seperated by white space. [I gather that on Unix there's a standard location for this file?] I want to end up with a file that contains a randomly-chosen selection of words. Actually, I'd like the end result to be a LaTeX file, containing sections, subsections, paragraphs and sentences. (Although obviously the actual sentences will be gibberish.) I'd like to be able to select how big the file should be, to within a few dozen characters anyway. Exact precision is not required. How would you do this? The approach I came up with is to slurp up the words like so: raw <- readFile "words.txt" let ws = words raw let n = length ws let wa = listArray (1,n) ws (I actually used lazy ByteStrings of characters.) So now I have an array of packed ByteStrings, and I can pick array indexes at random and use "unwords" to build my gibberish "sentences". The fun part is making a sentence come out the right size. There are two obvious possibilities: - Assume that all words are approximately N characters long, and estimate how many words a sentence therefore needs to contain to have the required length. - Start with an empty list and *actually count* the characters as you add each word. (You can prepend them rather than append them for extra efficiency.) I ended up taking the latter approach - at least at the sentence level. What I actually did was to write a function that builds lists of words. There is then another function that builds several sublists of approximately the prescribed lengths, inserts some commas, capitalises the first letter and appends a fullstop. This therefore generates a "sentence". After that, there's a function that builds several sentences of random size with random numbers of commas and makes a "paragraph" out of them. Next a function gathers several paragraphs and inserts a randomly-generated subsection heading. A similar function takes several subsections and adds a random section heading. In my current implementation, all of this is in the IO monad (so I can pick things randomly). Also, the whole thing looks very repetative and really if I thought about it harder, it ought to be possible to factor it out into something smaller and more ellegant. The clause function builds clauses of "approximately" the right size, and each function above that (sentence, paragraph, subsection, section) becomes progressively less accurate in its sizing. On the other hand, the final generated text always for example has 4 subsections to each section, and they always look visually the same size. I'd like to make it more random, but all the code works by estimating "roughly" how big a particular construct is, and therefore how many of then are required to full N characters. For larger and larger N, actually counting this stuff would seem somewhat inefficient, so I'm estimating. But that makes it hard to add more randomness without losing overall size control. The final file can end up being a fair way different in size to what I requested, and has an annoyingly regular internal structure. But essentially, it works. It would be nice to modify the code to generate HTML - but since it's coded so simple-mindedly, that would be a copy & paste job. Clearly, what I *should* have done is think more about a good abstraction before writing miles of code. ;-) So how would you guys do this?

11 23