- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Transactional in-memory model
by vlcakm＠tiscali.cz 23 Aug '05

23 Aug '05

> would the STM constructs in GHC 6.4 be suitable for your project? > jake Hi Jake, as far as I understand STM is does not exactly match my requirements - it is meant to support concurrent programming. But it is a great reading - thanks for pointing that out to me! I'll get to use it later when I learn more of Haskell in general. vlcak --------------------------------------------------------------------------------- Nokia 3120 - stribrny design a barevny displej jiz od 77 Kc http://ad.tiscali.com/adclick/CID=00027edc0000000000000000/SITE=CZ.TISCALI/…

1 0

RE: Random matrices
by Scherrer, Chad 23 Aug '05

23 Aug '05

> Ah ha. That'll do. > Lesson: avoid hidden space leaks in monads. Hmm, I'm still missing something. It seems a good lesson, but practically speaking, it doesn't help me any more than saying "write efficient programs". What could I have looked for in the original code to predict it may be leaky? Is there a way of thinking about this that can help me stop hitting space leaks like this? BTW, I really do appreciate the help. I've been amazed at the level of effort put forth by the Haskell community as a whole to help out newcomers. -Chad

2 1

RE: [Haskell-cafe] FFI and callbacks
by Simon Marlow 22 Aug '05

22 Aug '05

On 20 July 2005 14:35, John Goerzen wrote: > I'm looking at packaging an event-driven console widget set (CDK) for > Haskell using FFI. I know that other event-driven widget sets have > Haskell bindings, but I'm not quite sure how to make everything play > nice with forkIO. > > These systems generally have some sort of an opaque main loop, > implemented in C. This loop would usually never return, or perhaps > only return once the UI is destroyed. Is the library thread-safe or not? I mean OS-thread safe. If it is, then you're home and dry: just compile your program with GHC's -threaded option, and any foreign calls that need to run concurrently with Haskell threads must be declared "safe" (which is the default in fact, so instead I should really advise you to mark all calls that don't need to run concurrently as "unsafe", because that's good for performance). If the library isn't thread-safe, then you're in the same boat as Gtk and wxHaskell (I believe) where there are known problems with having a multithreaded Haskell GUI app. You can only have one OS thread (and hence only one Haskell thread) doing GUI operations, and that is the thread in the main loop. You have to somehow set up a communication between your other Haskell threads and the thread running the main loop - perhaps you can send requests of type (IO ()) down a channel to the main loop thread which wakes up occasionally to run them, for example. Cheers, Simon

5 8

RE: [Haskell-cafe] Re: Oracle + Haskell advice?
by Bayley, Alistair 22 Aug '05

22 Aug '05

> From: Keean Schupke [mailto:k.schupke@imperial.ac.uk] > > Still I now know that HaskellDB has significant limitations, and the > relational algebra approach I took is far more robust and flexable... > > ... there's no documentation. If anyone were interested in > using/contributing I could give CVS access to the code. Me too. Please. I'm quite interested in your relational algebra approach. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

Pattern match failure, then inconsistent function behavior
by Adam Wyner 22 Aug '05

22 Aug '05

Hi, I am getting a "pattern match failure", and then a function which worked right works wrong. I am using Hugs and Trex. While most of the other functions in my module work fine, the function "findCoordinatesUtil" generates an error, then misbehaves. The function takes a record and a list of records, then searches the list of records to find other records which are in a specified relationship with the input function. In the first example, it works fine: LexicalSemantics03> findCoordinatesUtil (giveActionFromLabel "Action6" testLexActions03) testLexActions03 [(label="Action7", xcond=["prop1","prop7","prop5"], ycond=["prop3","pr op4","neg-prop6"]),(label="Action08", xcond=["prop1","prop7","prop5"], ycond=["prop3","neg-prop6","prop5"]),(label="Action09", xcond=["prop1 ","prop7","prop5"], ycond=["prop3","neg-prop6","neg-prop1"])] However, when I run the function on a larger list of records (here testList01), it generates an error message. LexicalSemantics03> findCoordinatesUtil (giveActionFromLabel "Action33 " testList01) testList01 Program error: pattern match failure: map_v780 (instEq_v20 instEq_v11 Eq_== "neg-prop2") map_v780 INTERNAL ERROR: Error in graph Moreover, when I subsequently run the function, I get a different (and wrong) result -- label-"Action08" is missing. LexicalSemantics03> findCoordinatesUtil (giveActionFromLabel "Action6" testLexActions03) testLexActions03 [(label="Action7", xcond=["prop1","prop7","prop5"], ycond=["prop3","pr op4","neg-prop6"]),(label="Action09", xcond=["prop1","prop7","prop5"], ycond=["prop3","neg-prop6","neg-prop1"])] When I reload the module, it correctly works again. LexicalSemantics03> :r LexicalSemantics03> findCoordinatesUtil (giveActionFromLabel "Action6" testLexActions03) testLexActions03 [(label="Action7", xcond=["prop1","prop7","prop5"], ycond=["prop3","pr op4","neg-prop6"]),(label="Action08", xcond=["prop1","prop7","prop5"], ycond=["prop3","neg-prop6","prop5"]),(label="Action09", xcond=["prop1 ","prop7","prop5"], ycond=["prop3","neg-prop6","neg-prop1"])] I don't understand the pattern match failure or how to correct it. What is this error message telling me? Thanks, Adam Wyner

1 0

Haskell and artificial intelligence
by Santoemma Enrico 22 Aug '05

22 Aug '05

Hello, is there any group or person working on this topic in Haskell? I'm massaging some code for an autonomous agent, and I'd like to share ideas. Enrico

1 0

Re: Random matrices
by dons＠cse.unsw.edu.au 22 Aug '05

22 Aug '05

[Moved to haskell-cafe@] Chad.Scherrer: > Thanks, Don. I need some time to take a closer look at this. I'm > trying to see, what is it about the code you posted that makes it so > much more efficient? Is it the loop in the IO monad is compiled into > an honest-to-goodness loop? Is this specific to IO, or does it work > out this way for monads in general? Or maybe some gains were made by > switching from using StdGen with a specified seed to using the > OS-supplied random number generator? > > -Chad Ok, lets try to work this out a bit more closely, rather than just throwing IO at it. The code that produces the following profiles is attached at the end. Before: total time = 0.28 secs (14 ticks @ 20 ms) total alloc = 42,614,556 bytes (excludes profiling overheads) randomEntry Main 71.4 78.0 randomArray Main 21.4 19.6 tester Main 7.1 2.3 Add cost centers to each line of randomEntry: total time = 0.46 secs (23 ticks @ 20 ms) total alloc = 49,301,332 bytes (excludes profiling overheads) randomEntry Main 87.0 71.2 randomArray Main 13.0 16.9 tester Main 0.0 2.0 4 Main 0.0 3.2 3 Main 0.0 3.2 1 Main 0.0 3.2 Hmm. Lets try to force the value returned from randomEntry: total time = 0.14 secs (7 ticks @ 20 ms) total alloc = 17,691,948 bytes (excludes profiling overheads) randomEntry Main 85.7 79.4 randomArray Main 14.3 12.1 tester Main 0.0 5.7 1 Main 0.0 2.6 Hmm. Some progress, but not clear what to do next. Now, lets try that loop: total time = 0.10 secs (5 ticks @ 20 ms) total alloc = 17,722,552 bytes (excludes profiling overheads) randomEntry Main 100.0 79.2 tester Main 0.0 5.6 randomArray Main 0.0 12.3 1 Main 0.0 2.6 randomArray is a little faster, but still randomEntry is costing us. Ok, lets see what happens if we switch to using the global stdgen instead of threading our own: total time = 0.00 secs (0 ticks @ 20 ms) total alloc = 137,544 bytes (excludes profiling overheads) CAF System.Random 0.0 1.8 CAF GHC.Handle 0.0 1.1 CAF GHC.Float 0.0 36.3 randomEntry Main 0.0 26.4 Bang! So I think our problem is a space leak in the monad state. Just to check, lets get rid of the explicit loop: total time = 0.00 secs (0 ticks @ 20 ms) total alloc = 139,340 bytes (excludes profiling overheads) CAF System.Random 0.0 1.8 CAF GHC.Handle 0.0 1.0 CAF GHC.Float 0.0 35.8 randomEntry Main 0.0 26.0 randomArray Main 0.0 3.7 main Main 0.0 1.0 CAF Main 0.0 30.0 Ok, so it wasn't the loop. Lets try to squish this monad state a bit better - it's getting allocated a lot. How about we put the StdGen in a strict field of a data type. data S = S !StdGen randomEntry :: State S Float randomEntry = do (S g) <- get (x, g') <- return $ randomR (0,1) g put (S g') return x total time = 0.10 secs (5 ticks @ 20 ms) total alloc = 15,536,944 bytes (excludes profiling overheads) randomArray Main 80.0 76.9 1 Main 20.0 16.6 tester Main 0.0 6.4 Just taking the original code and wrapping the state in the S constructor more than halves the memory consumption (compared to the original code), but doesn't squish the space leak .. lots of S's are getting allocated. How about we stick the StdGen in an STRef inside the ST monad (basically like the stdGen IORef, but not in IO): total time = 0.00 secs (0 ticks @ 20 ms) total alloc = 160,760 bytes (excludes profiling overheads) CAF System.Random 0.0 1.5 CAF GHC.Float 0.0 31.1 tester Main 0.0 2.3 randomEntry Main 0.0 33.3 randomArray Main 0.0 4.1 CAF Main 0.0 25.7 Ah ha. That'll do. Lesson: avoid hidden space leaks in monads. -- Don Here's the final ST code: ------------------------------------------------------------------------ import Control.Monad.ST import System.Random import Data.Array.Diff import Data.Array.Unboxed import Data.STRef import Control.Monad type Vector = UArray Int Float type Matrix = DiffArray Int Vector randomEntry :: STRef s StdGen -> ST s Float randomEntry r = do g <- readSTRef r (x, g') <- return $ randomR (0,1) g writeSTRef r g' return x randomArray :: (IArray arr a, Monad m) => Int -> m a -> m (arr Int a) randomArray n x = sequence (replicate n x) >>= return . listArray (1,n) tester :: Int -> [Matrix] tester n = runST (do ref <- newSTRef (mkStdGen 1) let randomMatrix i j = randomArray i $ randomVector j randomVector n = randomArray n (randomEntry ref) liftM repeat $ randomMatrix n n) main :: IO () main = print $ ((tester 10) !! 10000) ! 5 And here's some of the other versions of the code, if you're interested, to see how I was thinking. ------------------------------------------------------------------------ -- Generate a random number from the unit interval -- randomEntry :: State S Float -- randomEntry :: IO Float randomEntry = do (S g) <- {-# SCC "1" #-} get (x, g') <- {-# SCC "2" #-} return $ randomR (0,1) g {-# SCC "3" #-} put (S g') {-# SCC "4" #-} return x randomEntry = getStdRandom (randomR (0,1)) -- Build an array of n random things -- randomArray :: (IArray arr a) => Int -> State StdGen a -> State StdGen (arr Int a) -- randomArray :: (IArray arr a) => Int -> State S a -> State S (arr Int a) randomArray n x = mapState arr . sequence $ replicate n x where arr (a,s) = (array (1,n) $ zip [1..n] a, s) randomArray n x = do let loop i | i == 0 = return [] | otherwise = do f <- {-# SCC "a1" #-} x fs <- {-# SCC "a3" #-} loop (i-1) {-# SCC "a3" #-} return (f : fs) fs <- {-# SCC "a4" #-} loop n {-# SCC "a5" #-} return $ listArray (1,n) fs randomArray n x = do fs <- sequence (replicate n x) return $ listArray (1,n) fs -- A random vector is an array of random entries -- randomVector :: Int -> IO Vector -- randomVector :: Int -> State StdGen Vector -- randomVector :: Int -> State S Vector randomVector n = randomArray n randomEntry -- a random matrix is an array of random vectors. -- randomMatrix :: Int -> Int -> State StdGen Matrix -- randomMatrix :: Int -> Int -> IO Matrix randomMatrix i j r = randomArray i $ randomVector j tester n = fst $ runState vals $ S (mkStdGen 1) where vals = sequence . repeat $ randomMatrix n n tester n = unsafePerformIO $ do setStdGen (mkStdGen 1) liftM repeat $ randomMatrix n n > > -----Original Message----- > From: Donald Bruce Stewart [mailto:dons@cse.unsw.edu.au] > Sent: Fri 8/19/2005 7:42 PM > To: Scherrer, Chad > Cc: haskell(a)haskell.org > Subject: Re: [Haskell] Random matrices > > Chad.Scherrer: > > > > I'm doing some statistical calculations, and I decided to > > try this out in Haskell to see how it goes. I'm really > > enjoying using the language, so I hope I can straighten this > > out so I can keep using it at work. > > > > I keep getting stack overflows, so I think my code must be > > too lazy somewhere (that's what that means, right?) Here is > > my code to build random vectors and matrices. > > I was suspicious about all those zips and repeats, so did a bit of > profiling. This only revealed that the creation of random floats was > chewing up about 70% of time and space. Still suspicious of that > replicate code, I decided to rewrite it as a loop (I moved the code > into the IO monad just because it is easier to hack in IO). This fixed the > issue. > > -- Don > > Before: > > paprika$ ghc -package mtl -O -prof -auto-all N.hs > paprika$ ./a.out +RTS -p > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. > > total time = 0.16 secs (8 ticks @ 20 ms) > total alloc = 42,614,984 bytes (excludes profiling overheads) > > COST CENTRE MODULE %time %alloc > randomEntry Main 50.0 78.0 > randomArray Main 50.0 19.6 > > ------------------------------------------------------------------------ > > After: > paprika$ ghc -O -prof -auto-all M.hs > paprika$ ./a.out +RTS -p > array (1,10) [(1,0.73394084),(2,0.39095977),(3,0.18828022),(4,0.19094983),(5,0.83119744),(6,0.3594179),(7,0.43519533),(8,0.39867708),(9,0.15676379),(10,0.4503187)] > > total time = 0.00 secs (0 ticks @ 20 ms) > total alloc = 141,368 bytes (excludes profiling overheads) > > COST CENTRE MODULE %time %alloc > CAF System.Random 0.0 5.6 > CAF GHC.Handle 0.0 1.0 > CAF GHC.Float 0.0 35.2 > randomEntry Main 0.0 25.7 > > ------------------------------------------------------------------------ > > import Data.Array.Unboxed > import Data.Array.Diff > import System.Random > import Control.Monad > > type Vector = UArray Int Float > type Matrix = DiffArray Int Vector > > -- Generate a random number from the unit interval > randomEntry :: IO Float > randomEntry = getStdRandom (randomR (0,1)) > > -- Build an array of n random things > randomArray :: (IArray arr a) => Int -> IO a -> IO (arr Int a) > randomArray n x = do > let loop i | i == 0 = return [] > | otherwise = do f <- x > fs <- loop (i-1) > return (f : fs) > fs <- loop n > return $ listArray (1,n) fs > > -- A random vector is an array of random entries > randomVector :: Int -> IO Vector > randomVector n = randomArray n randomEntry > > -- a random matrix is an array of random vectors. > randomMatrix :: Int -> Int -> IO Matrix > randomMatrix i j = randomArray i (randomVector j) > > tester :: Int -> IO [Matrix] > tester n = liftM repeat $ randomMatrix n n > > main :: IO () > main = tester 10 >>= \as -> print $ (as !! 10000) ! 5 > > ------------------------------------------------------------------------

1 0

Transactional in-memory model
by Martin Vlk 21 Aug '05

21 Aug '05

Hi folks, I am new to Haskell, coming from an object-oriented realm. As an exercise I am trying to develop an API for accessing/changing services configuration in a SysV-like init environment. Being object-oriented I have defined a model of runlevels/services and a parser that creates instances of these structures from the underlying files. That way my program is able to interrogate the current state of the services configuration. Now I would like to ask how to go about designing the part that will make changes to the config in respect to the following requirement. I want the API to allow making changes only to the model and then applying them back to the filesystem at once. This is to support UI where the user will make various changes and then hit "Apply" or "Cancel". I am imagining this as a sort of simple transactional behaviour of the in-memory model. At the moment I am thinking of passing the whole model around through the various API functions, that will make the changes, but there are many questions to be answered. I need to keep the original model state and a stack of the changes made so that at commit-time I can figure out what has been changed. Also some changes might affect each other (add service followed by remove service, etc.). Anyway the main question is how should such a scenario be approached. Can anyone throw in some ideas to get me started? It might well be that this whole idea of a model with changing state is wrong in respect to FP. If so, what would the right way be? Cheers vlcak

3 2

XML Toolbox Question
by Dimitry Golubovsky 21 Aug '05

21 Aug '05

Hi, How can I obtain a list of all <a> tags from the result of parseHtmlContent? Unfortunately, the Haddock documentation coming with the package is not rich on examples. Any suggestions will be appreciated. Dimitry Golubovsky Middletown, CT

2 1

map applications
by Brian McQueen 20 Aug '05

20 Aug '05

I have a simple list like this: qlist = ["ll", "kkkkkkk", "ddddd"] Why is it OK to do this: qwrap [] = putStrLn ":" qwrap (a:as) = do putStrLn a qwrap as qwap qlist but not this: map putStrLn qlist What is going on in the map function? McQueen

2 1

Oracle + Haskell advice?
by Brian Strand 20 Aug '05

20 Aug '05

Hello, I'm thinking about (re)writing some perl code in Haskell (for performance and correctness reasons). Has anyone done much with Oracle and Haskell? So far I've gotten takusen (http://cvs.sf.net/viewcvs.py/haskell-libs/libs/takusen/) to compile and run on my Suse 9.3 x86-64 box against Oracle 10.1. If this pans out the production environment is a bunch of mid-size (4gb+ mem, 1tb+ disk) Oracle boxes typically processing millions of rows per day. Before I wade in too deep, I'm wondering if anyone has done much "business app" programming with Haskell (where "business app" is rather fuzzily defined as database access, web UIs, interfacing with various systems over ip, etc.). Does anyone have any advice? eg "don't go there" or "works great!" or "try OCaml" :) . Thanks, Brian

5 5

RE: [Haskell-cafe] Re: Oracle + Haskell advice?
by Bayley, Alistair 19 Aug '05

19 Aug '05

> From: Brian Strand [mailto:bstrand@switchmanagement.com] > > So far Takusen is working great (once I figured out the > proper incantations > for getting "select * from dual" working, things went much > faster...). We > don't currently use LOBs, and very rarely call stored > procedures, so there's a > happy match between Takusen's missing features and our unused > features ;) One > thing we do use extensively is bind parameters; do you have > any hints on > getting doQueryBind working, or pointers on what's left to do > there? And is > the version in CVS on sf.net a good place to start? Hmm... I assume that you're using the experimental version from CVS, as you've mentioned doQueryBind, which is not in the Main branch. What problems are you having with bind parameters? Have you seen the tests in Database.Test.Enumerator? Specifically, the selectBindInt and selectBindDate functions demonstrate simple usage of bind parameters. There are a couple of implementation notes which might affect you: - I think you have to specify the type of the bind parameter list (i.e. help the type-checker) - user modules (like Database.Test.Enumerator) probably need to specify these pragmas: {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-overlapping-instances #-} - bind parameters are specified with ?'s, and we convert those to the Oracle :x syntax. I think you should be able to use the :x syntax too though; I believe it will be passed through unmolested. Reviewing at the bind variable code has highlighted a glaring design flaw: you can only pass homogenous lists of bind values! We originally had a design where you passed a list of bind actions (a monadic action which returned ()). I think that in my zeal to reduce programmer effort I have reduced this to a list of values (to which we apply the bind action in the library). Maybe that's what's biting you... I'd better get onto that sharpish. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

RE: [Haskell-cafe] Oracle + Haskell advice?
by Bayley, Alistair 19 Aug '05

19 Aug '05

> From: Brian Strand [mailto:bstrand@switchmanagement.com] > > I've gotten takusen > (http://cvs.sf.net/viewcvs.py/haskell-libs/libs/takusen/) > to compile and run on my Suse 9.3 x86-64 box against Oracle > 10.1. Cool. I'm keen for feedback. I can also give general advice as far as interfacing to Oracle is concerned. To be fair, Takusen is usable, but far from feature-complete (no support for BLOBs, CLOBs, invoking procedures). You might want to compare it to HaskellDB over ODBC, if you can get HaskellDB running (I don't know how usable ODBC-on-Unix is). HaskellDB is a higher-level approach to database access, and might be better suited to "business apps". > Before I wade in too deep, I'm wondering if anyone has done > much "business > app" programming with Haskell (where "business app" is rather > fuzzily defined > as database access, web UIs, interfacing with various systems > over ip, etc.). As for the other stuff, here are a few projects which might interest you. I believe these represent the state-of-the-art in Haskell as far as this sort of stuff is concerned: http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ : WASH, for building browser-based apps http://www.haskell.org/haxr/ : HaXR, for XML-RPC (the "interfacing with various systems over ip" requirement) http://www.repton-world.org.uk/mediawiki/index.php/HAIFA_Wiki : HAIFA. Looks like it does SOAP. See also: http://haskell.org/~shae/haifa_tmr.pdf There are also a few XML libraries around; I can't comment on how well these work. It should be clear that there's not yet one clear bundle or approach that we can point to and say "here, use this". Like, say, Ruby-on-rails, Zope, Seaside, etc. Things are still a bit more DIY in Haskell land. I recommend starting with WASH and adding what you need from there. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

static typing and interactivity
by Ketil Malde 19 Aug '05

19 Aug '05

Hi, One slight annoyance using Haskell is the inability to load modules with type problems in the interactive environment (i.e. GHCi). When I have a type error, it would be nice to have an interactive way to explore what the compiler thinks about the types involved -- as it is, I have to resort to adding type signatures more or less at random to narrow down the problem. I'm not sure if it is technically feasible to (partially) load a module with definitions that fail type checking, but if it were, I thing it would make developing Haskell programs even nicer :-) -k -- If I haven't seen further, it is by standing in the footprints of giants

5 4

RE: [Haskell-cafe] Re: [Haskell] pros and cons of static typing andside effects ?
by Ralf Lammel 17 Aug '05

17 Aug '05

I don't even want this feature. :-) The point being that datatype declarations, *as such*, are explicit anyhow. Why bother about the explicit quantifiers then? Of course, in a language with inferred datatypes I would mind. That's an interesting question! I also wouldn't (yet?!) support this feature request because we will still confuse beginners, but that's just my feeling. Ralf > -----Original Message----- > From: Stefan Holdermans [mailto:stefan@cs.uu.nl] > Sent: Tuesday, August 16, 2005 11:48 PM > To: Ralf Lammel > Cc: haskell-cafe(a)haskell.org; Benjamin Franksen > Subject: Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing > andside effects ? > > Ralf, > > > Technically this is trivial it seems. I think that some people > > consider this proposal a problem because typos (misspelled type > > parameters) immediately lead to the accidental exploration of a more > > advanced type-system feature and correspondingly more involved error > > messages. Of course, the type checker could perhaps consider adding > > "Did you really mean to ...?". > > Well, okay, but as soon as the type checker starts to asking these > questions, I would immediately start adding the explicit quantifiers, > just to get rid of those annoying warning messages. ;) So one would we > also need to be able to control the behaviour of the type checker with > respect to these warnings by means of a compiler flag like > "fno-warn-on-implicit-existential-quantification". All of this is, of > course, still trivial. :) > > Have we thought about it enough to make it a feature request? > > Regards, > > Stefan

2 1

RE: [Haskell-cafe] Re: [Haskell] pros and cons of static typing andside effects ?
by Ralf Lammel 17 Aug '05

17 Aug '05

Technically this is trivial it seems. I think that some people consider this proposal a problem because typos (misspelled type parameters) immediately lead to the accidental exploration of a more advanced type-system feature and correspondingly more involved error messages. Of course, the type checker could perhaps consider adding "Did you really mean to ...?". Ralf > I once read a paper about type classes and existentials (can't remember > exact title or author, was it Läufer?) where the proposal was to make > existential quantification implicit (just as the universal one is in > Haskell98). That is, any type variable that appears on the rhs of a > data type, but not on the lhs, is implicitly existentially quantified, > as in > > data XWrap = Show a => XWrap a > > I always thought this was a pretty nice idea.

2 1

Seeking a small bug-fix for previously-posted code
by Andy Elvey 17 Aug '05

17 Aug '05

Hi all - I'm trying to run some code posted recently on this list ( the exact URI is as follows - http://comments.gmane.org/gmane.comp.lang.haskell.cafe/7860 ( The reason I'm doing this is because this code is quite close to what I'm trying to do. ) Anyway, I saved the code in a file called andy1.hs . The exact code is as follows - module Main where readVecs :: String -> IO [Vector3 GLfloat] readVecs f = do str <- readFile f let mkVec [x,y,z] = Vector3 x y z return $ map (mkVec . read . words) $ lines str ( I can see what the code seems to be doing : it's reading the file line-by-line, splitting it into "words", and filling the vectors with them. Not too bad a guess for a "Haskellista" of a few minutes standing ..... ;-) I created a small file with whitespace-separated floats so that I could run the above code. This data file looks like this - 23.596 38.201 79.903 32.647 65.559 15.438 21.648 34.978 90.089 55.587 76.763 96.634 When I run the above code (in GHCi , version 6.4) I get the message - Prelude> :load andy1 Compiling Main ( andy1.hs, interpreted ) andy1.hs:4:7: The last statement in a 'do' construct must be an expression Failed, modules loaded: none. So - I'm just wondering if anyone can see how the above code should be fixed in order to run. And just one last question - If the file looked like this (with column headings ) Name Ethnicity Age Mary_Smith NZ_European 27 Joe_Brown NZ_European 34 John_Watson Canadian 45 Mike_Tangaroa NZ_Maori 38 - what change would the above code need to run? Very many thanks in advance ... - Andy

3 7

Re: [Haskell] pros and cons of static typing and side effects ?
by Mark Carroll 16 Aug '05

16 Aug '05

The previous comments make sense to me. The lots-of-unit-tests aspect of static typing I find really useful, far exceeding any BDSM cost. If I'm engaging in exploratory programming, the type inference combined with the ability to write 'error "armadillo"' in stubs for values I can't be bothered to generate right now really works conveniently for me. Although I agree that lots-of-lists is very handy in early prototyping, I don't feel at all constrained by using homogeneous lists, although very occasionally I may use existential types, and the way I write programmes is exactly to think in advance and then write the code: to do otherwise just wastes my time because then the code doesn't work in some confusing way and I have to do that thinking I postponed to figure out why - or, if it does work, I have to think about it to satisfy myself that appearances aren't deceiving. I'm not quite sure what macros would look like in Haskell, but I've not missed those either. In Lisp I would tend to use them for things that involved changing the values of variables, but that's not really a Haskellish thing to be doing anyway. Mind you, I learned Lisp after learning ML, so to some extent I was thinking in ML when writing in Lisp. Alas, dead-tree versions of "On Lisp" are hard to come by affordably, but I am now trying to learn more about what I might have missed about Lisp. I find monads useful because I find it a helpful debugging aid for functions to be quite clear about what side effects they may want to have. I posted this to Haskell-Cafe instead of the main Haskell list, because I'm rambling a bit. Puzzled Haskell-Cafe readers may like to check http://www.mail-archive.com/haskell@haskell.org/msg17009.html -- Mark

4 7

Creating a Haskell section in Autoconf Macro Archive
by Peter Simons 12 Aug '05

12 Aug '05

Fellow Haskell'ers, I've been maintaining the site <http://autoconf-archive.cryp.to/> for a while now, and I can't help but notice that there is no Haskell section. I know that GHC comes with a lot of useful Haskell-related Autoconf macros, so does Darcs, and so do a lot of other projects too. Thus, I was wondering whether the respective macro authors would be willing to submit their macros to the archive for distribution, so that other software developers around the world can find them, and re-use them. To have a macro added to the archive, all you need to do is to e-mail it to me in the proper mark-up format, so that the software which generates the archive can extract the necessary meta information and documentation. I'll use one of David Roundy's macros as an example to show what that looks like. Hope you don't mind, David. ;-) Here it is: | dnl @synopsis AX_TRY_COMPILE_GHC(PROGRAM, [ACTION-IF-TRUE], [ACTION-IF-FALSE]) | dnl | dnl AX_TRY_COMPILE_GHC tries to compile and link the given | dnl program using $GHC for the compiler, and $GHCFLAGS as | dnl flags passed to the compiler. | dnl | dnl @category Haskell | dnl @author David Roundy <droundy(a)abridgegame.org> | dnl @version 2005-08-12 | dnl @license AllPermissive | | AC_DEFUN([AX_TRY_COMPILE_GHC],[ | cat << \EOF > conftest.hs | -- [#]line __oline__ "configure" | [$1] | EOF | rm -f Main.hi Main.o | if AC_TRY_COMMAND($GHC $GHCFLAGS -o conftest conftest.hs) && test -s conftest | then | dnl Don't remove the temporary files here, so they can be examined. | ifelse([$2], , :, [$2]) | else | echo "configure: failed program was:" >&AC_FD_CC | cat conftest.hs >&AC_FD_CC | echo "end of failed program." >&AC_FD_CC | ifelse([$3], , , [ rm -f Main.hi Main.o | $3 | ])dnl | fi]) One of the more interesting keywords is @license, obviously. The license recommended by the Free Software Foundation for Autoconf macros is the all-permissive license, which reads like this: | Copying and distribution of this file, with or without | modification, are permitted in any medium without royalty | provided the copyright notice and this notice are preserved. Other valid choices are "GPL2", "GPLWithACException", and "BSD". A more thorough description of the keywords is available on the archive's homepage. Peter

2 2

Re: [Haskell] pros and cons of static typing and side effects ?
by Bernard Pope 12 Aug '05

12 Aug '05

[Moved to the Haskell cafe] It's Friday afternoon here so I thought I'd join in the fun. On Thu, 2005-08-11 at 23:01 -0400, ajb(a)spamcop.net wrote: > While you can't be certain that once your code typechecks, it's bug-free > (though that does often happen), you can be almost guaranteed that if > your code typechecks after a refactoring, the refactoring didn't > introduce any bugs. (I tend to agree with ajb's sentiment, but I'll play the devil's advocate anyway). Perhaps we can reach a fixed point of violent agreement? I'm a bit concerned with "can't be certain" on the one hand, and "_almost_ guaranteed", on the other. I guess there are nuances to be explored here, and it is all about degree of confidence. Sometimes I have high confidence in my refactoring, like introducing a state monad. Other times I have much less confidence, like swapping the order of arguments in numerical calculations. However, if it weren't for static type checking then I would be much less game to even _try_ introducing a state monad in my code in the first place. (Maybe that's just me). Another colleague of mine gave the opinion that one of the reasons higher-order code is less common in Prolog than Haskell is that in Prolog does not have static type checking (it's just one factor out of many). It seems to me like static type checking has the capacity to make some refactorings much less heroic than they would be in the non-static setting. That's my "log on the fire" for today. Bernie.

1 0

Re: [Haskell-cafe] Creating a Haskell app to do crosstabs
by Andy Elvey 11 Aug '05

11 Aug '05

Greg Buchholz wrote: >Andy Elvey wrote: > > >>a) Using Haskell to read a delimited file (with column-headings) into a >>columnar or tabular data-structure - >> >> >> Parsec (http://www.cs.uu.nl/~daan/parsec.html) is a great parsing >>library in Haskell. >> >> >>Greg Buchholz >> >> >> Hi Greg - thanks very much for this! I'll check Parsec out - thanks for the link - - Andy

1 0

Creating a Haskell app to do crosstabs
by Andy Elvey 11 Aug '05

11 Aug '05

Hi everyone - I'm a relative newcomer to Haskell, and am very much besotted with it - it's a great language! :-) At the moment, I'm in the early stages of putting together a little "Haskell-like" language using the Spirit parser framework (Spirit is part of the Boost C++ libraries). Spirit also has a functional-programming "sister" library (Phoenix), which includes lambdas, lazy functions and lots more. Phoenix is currently being merged with the Boost Lambda Library. ( Sorry for the off-topic digression - just giving the background to what I'm doing .... ;-) ) I've done a couple of "toy parsers" for Spirit already, but now I'm looking to do something that is more of a challenge - doing a small-ish Haskell-like language. The language is aimed at being able to read in a comma-delimited file (with column-headings), and putting the data into "columns". ( I envisage maybe a Haskell "pair". The first item being the column heading, the second being a list, with the data in it. ) Then, the user would select one of those "columns" for a "page" variable (that one would be optional), and one or more "columns" for the crosstab rows and columns. What I'm needing to do is to first put together the code in Haskell itself, and get it running. Then, that will give me a good feel as to how much of "core" Haskell I need to implement, in order to do the crosstab app. So, I was wondering - has anyone in the Haskell community used Haskell to do crosstabs? ( And if so, is there any code available? ). Any help in the two areas - a) Using Haskell to read a delimited file (with column-headings) into a columnar or tabular data-structure - b) Using Haskell to do crosstabs - - would be very welcome! I should also stress that full credit will be given to the writers of any code supplied. Very many thanks in advance for any help received! - - Andy

3 4

RE: [Haskell-cafe] Functional dependenices in class declarations
by Simon Peyton-Jones 11 Aug '05

11 Aug '05

It's intentional. Consider this data type declaration data B b = MkT (A a b) Should that be accepted? The only thing it could possibly mean would be data B b = MkT (forall a. A a b) and I suppose that might possibly be useful. But in this case you're also saying that "a" determines "b". But you can hardly say *forall* a, if the choice of a determines the (fixed by context) b. These functional dependencies are tricky things. Martin Sulzmann and I wrote a paper about some of the trickiness (http://research.microsoft.com/%7Esimonpj/Papers/fd-chr/index.htm) and we're working on a journal version. My wild guess is that you are trying to convert an O-O idiom into Haskell, and that's led you to a rather strange program. Maybe there's another way to do it. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Frank | Sent: 08 August 2005 18:17 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] Functional dependenices in class declarations | | In ghc 6.4 (fine work - many gratulations to all who did it!) it is | permitted | to have type parameters which are reachable (7.4.3.1 context of type | signatures). | I tried the following: | | module TypeDependencies where | | class A a b | a -> b | | class (A a b) => B b where | op :: a -> a | | x :: A a b => a -> a | x = id | | Which compiles fine for the function x, but does complain | "not in scope: type variable 'a' " for the class (A a b) => B b. | | Is this an intentional restriction that 'reachable' type variables are only | permitted in type definitions, but not in classes? or do I misunderstand | something? | | Any help appreciated! | Andrew Frank | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] Internal error: scavenge_one
by Simon Marlow 09 Aug '05

09 Aug '05

On 08 August 2005 20:22, Dinh Tien Tuan Anh wrote: > i have the following error when running my program: > > <interactive>: internal error: scavenge_one: strange object 47 > > does anyone know what it is ? Yes, it's probably a bug. Please report it to glasgow-haskell-bugs(a)haskell.org, giving your GHC version, platform, the program that produces the bug, and any other relevant options that we need to reproduce it. Cheers, Simon

1 0

RE: [Haskell] unsafePerformIO and optimizations
by Simon Marlow 09 Aug '05

09 Aug '05

On 06 August 2005 15:24, Wolfgang Jeltsch wrote: > First, what is the problem with inlining a function call? Say, I > have a function f defined as follows: > > f :: Char -> () > f c = unsafePerformIO (putChar c) > > If inlining is allowed, the expression f '*' becomes > > unsafePerformIO (putChar '*'). > > Is this a problem? Or is inlining dangerous in other situations? > > On the other hand, I can see that inlining non-functions could cause > harm. Say I have something like this: > > u :: () > u = unsafePerformIO (putChar '*') > > Now, inlining u would transform (u,u) to > > (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) > > which could result in putChar '*' being executed multiple times. So > why does the library documentation only talk about disabling inlining > of functions? Well, you're right - it's all about sharing of redexes of the form (unsafePerformIO e). When you write an unsafePerformIO with a side effect, you probably have an intuition about when you expect that redex to be reduced. In your example above, you're probably thinking "it'll be executed whenever f is called". However, optimisations can invalidate your intuition in many ways, by increasing (or reducing) sharing of the unsafePerformIO redex. Inlining 'f' itself isn't a problem, because that doesn't change sharing, as you pointed out. However, it might expose potential for *reducing* sharing, because (unsafePerformIO (putChar '*')) is now a visibly constant expression, it only needs to be evaluated once per run of the program. > I understand that common subexpression elimination could cause harm. > It could transform the expression > > (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) > > to > > let > u = unsafePerformIO (putChar '*') > in > (u,u), > > couldn't it? This would result in the I/O action be performed at > most once which is not what was intended. But couldn't the same > thing also happen if I use the expression (f '*',f '*'), probably in > a different module? Well, quite. > Does this mean that I have to use -fno-cse not > only in the module which contains the unsafePerformIO application but > also in every other module which uses unsafePerformIO indirectly via > f or functions using f? This way leads to madness - GHC's optimisations are simply not designed to provide any kind of guarantee about maintaining sharing properties. The guidelines we've given for unsafePerformIO are enough to cover simple uses like global variables. We should probably amend the documentation to say this. Cheers, Simon

2 1

Functional dependenices in class declarations
by Frank 08 Aug '05

08 Aug '05

In ghc 6.4 (fine work - many gratulations to all who did it!) it is permitted to have type parameters which are reachable (7.4.3.1 context of type signatures). I tried the following: module TypeDependencies where class A a b | a -> b class (A a b) => B b where op :: a -> a x :: A a b => a -> a x = id Which compiles fine for the function x, but does complain "not in scope: type variable 'a' " for the class (A a b) => B b. Is this an intentional restriction that 'reachable' type variables are only permitted in type definitions, but not in classes? or do I misunderstand something? Any help appreciated! Andrew Frank

2 1

RE: [Haskell-cafe] subRegex bug?
by Simon Marlow 04 Aug '05

04 Aug '05

On 11 May 2005 22:22, S. Alexander Jacobson wrote: > Am I misunderstanding the regex docs? > > *MyMod> subRegex (mkRegex "\\." ) "foo.bar" "blah" > "foo*** Exception: Text.Regex.Posix.regcomp: error in pattern Fixed now, thanks. Simon

1 0

RE: [Haskell-cafe] Problem type checking class-method implementation
by Ralf Lammel 03 Aug '05

03 Aug '05

Stefan, the problem can be spotted in the following erased version of your program. data Identity a instance Monad Identity class (Monad m) => IsItem m i where processItem :: i -> m () class (Monad m) => IsProcessor p m | m -> p where process :: (IsItem m i) => i -> m () newtype Item m = Item {processItemImpl :: m ()} newtype ProcessorT p m a = ProcessorT {runProcessorT :: m a} instance (Monad m) => Monad (ProcessorT p m) instance (Monad m) => IsProcessor p (ProcessorT p m) newtype Processor p a = Processor {unwrap :: ProcessorT p Identity a} instance Monad (Processor p) where castItem :: (IsItem (Processor p) i) => i -> Item (ProcessorT p Identity) castItem = undefined instance IsProcessor p (Processor p) where process = Processor . process . castItem Recall the type error: Could not deduce (IsItem (Processor p1) i) from the context (IsProcessor p (Processor p), Monad (Processor p), IsItem (Processor p) i) The problem is basically in here: instance IsProcessor p (Processor p) where process = Processor . process . castItem By specializing function signatures according to the instance head, and by applying type checking constraints for functional composition, we get these types: Processor :: ProcessorT p Identity () -> Processor p () process :: process :: ( IsProcessor p (ProcessorT p Identity) , IsItem (ProcessorT p1 Identity) () ) => Item (ProcessorT p1 Identity) -> ProcessorT p Identity () castItem :: (IsItem (Processor p1) i) => i -> Item (ProcessorT p1 Identity) The problem is the type-scheme polymorphic result type of castItem which is consumed by a type-variable polymorphic but type-class bounded argument type of process. The constraint of this application process, i.e., IsItem (Processor p1) i is the one GHC asks for. (Do the hugs test :-)) Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Stefan Holdermans > Sent: Wednesday, August 03, 2005 1:01 AM > To: haskell-cafe > Subject: [Haskell-cafe] Problem type checking class-method implementation > > Dear Haskellers, > > Yesterday I stumbled upon a problem type checking a program involving > multi-parameter type classes. GHC rejected the program; still, I was > not immediately convinced it contained a type error. Having given it > some more thoughts, I start to suspect that the type checker is in err > and that the program is well-typed after all. But, well, I might be > overlooking something obvious... > > I have reduced my code to a small but hopelessly contrived example > program exposing the problem. Please hang on. > > Because we employ multi-parameter type classes, we need the Glasgow > extensions: > > {-# OPTIONS -fglasgow-exts #-} > > Let's start easy and define the identity monad: > > newtype Identity a = Identity {runIdentity :: a} > > instance Monad Identity where > return = Identity > Identity a >>= f = f a > > Then, let's introduce the foundations for the (contrived) example: > > class (Monad m) => IsItem m i where > processItem :: i -> m () > > class (Monad m) => IsProcessor p m | m -> p where > process :: (IsItem m i) => i -> m () > -- ...some more methods, possibly involving p... > > So, an item is something that can be processed within the context of a > certain monad, and a processor is something that can process an item of > an appropriate type. Note the functional dependency from m to p: a > processor type m uniquely determines the type of the processing context > p. > > Before we move on, consider this canonical item type, which is just a > one-field record representing an implementation of the IsItem class: > > newtype Item m = Item {processItemImpl :: m ()} > > The corresponding instance declaration is obvious: > > instance (Monad m) => IsItem m (Item m) where > processItem = processItemImpl > > Furthermore values of every type that is an instance of IsItem can be > converted to corresponding Item values: > > toItem :: (IsItem m i) => i -> Item m > toItem = Item . processItem > > Please stick with me, for we are now going to implement a monad > transformer for processors (which, for this example, is really just the > identity monad transformer): > > newtype ProcessorT p m a = ProcessorT {runProcessorT :: m a} > > instance (Monad m) => Monad (ProcessorT p m) where > return = ProcessorT . return > ProcessorT m >>= f = ProcessorT (m >>= runProcessorT . f) > > instance (Monad m) => IsProcessor p (ProcessorT p m) where > process = processItem > > Then, finally, we use this transformer to derive a processor monad: > > newtype Processor p a = Processor {unwrap :: ProcessorT p Identity a} > > runProcessor :: Processor p a -> a > runProcessor = runIdentity . runProcessorT . unwrap > > So, we just make sure that Processor is a monad: > > instance Monad (Processor p) where > return = Processor . return > Processor m >>= f = Processor (m >>= unwrap . f) > > Now all what is left to do is declare Processor an instance of > IsProcessor. To this end, we need to be able to cast items for > Processor p to items for ProcessorT p Identity (for all p). The > following function takes care of that: > > castItem :: (IsItem (Processor p) i) => i -> Item (ProcessorT p > Identity) > castItem = Item . unwrap . processItem > > Note that up 'til now everything is fine: GHC is happy, I am happy. But > then, > when all the hard work is done, and we just only have to connect things > properly, it just breaks: > > instance IsProcessor p (Processor p) where > process = Processor . process . castItem > > After adding this last instance declaration, GHC happily reports: > > Processor.hs:56:24: > Could not deduce (IsItem (ProcessorT p Identity) > (Item (ProcessorT p1 Identity))) > from the context (IsProcessor p (Processor p), > Monad (Processor p), > IsItem (Processor p) i) > arising from use of `process' at Processor.hs:56:24-30 > Probable fix: > add (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 > Identity))) > to the class or instance method `process' > or add an instance declaration for > (IsItem (ProcessorT p Identity) > (Item (ProcessorT p1 Identity))) > In the first argument of `(.)', namely `process' > In the second argument of `(.)', namely `process . castItem' > In the definition of `process': process = Processor . (process . > castItem) > > Processor.hs:56:34: > Could not deduce (IsItem (Processor p1) i) > from the context (IsProcessor p (Processor p), > Monad (Processor p), > IsItem (Processor p) i) > arising from use of `castItem' at Processor.hs:56:34-41 > Probable fix: > add (IsItem (Processor p1) i) to the class or instance method > `process' > or add an instance declaration for (IsItem (Processor p1) i) > In the second argument of `(.)', namely `castItem' > In the second argument of `(.)', namely `process . castItem' > In the definition of `process': process = Processor . (process . > castItem) > > It seems to me that the type checker fails to unify p and p1 where it > really should. But once again: I may be wrong here. So, could you > either explain to me what I'm missing here and why this program is > indeed ill-typed, or confirm that it's really just GHC that should be > accepting this program. > > I have attached a file Processor.hs containing the example program.

2 1

Problem type checking class-method implementation
by Stefan Holdermans 03 Aug '05

03 Aug '05

Dear Haskellers, Yesterday I stumbled upon a problem type checking a program involving multi-parameter type classes. GHC rejected the program; still, I was not immediately convinced it contained a type error. Having given it some more thoughts, I start to suspect that the type checker is in err and that the program is well-typed after all. But, well, I might be overlooking something obvious... I have reduced my code to a small but hopelessly contrived example program exposing the problem. Please hang on. Because we employ multi-parameter type classes, we need the Glasgow extensions: {-# OPTIONS -fglasgow-exts #-} Let's start easy and define the identity monad: newtype Identity a = Identity {runIdentity :: a} instance Monad Identity where return = Identity Identity a >>= f = f a Then, let's introduce the foundations for the (contrived) example: class (Monad m) => IsItem m i where processItem :: i -> m () class (Monad m) => IsProcessor p m | m -> p where process :: (IsItem m i) => i -> m () -- ...some more methods, possibly involving p... So, an item is something that can be processed within the context of a certain monad, and a processor is something that can process an item of an appropriate type. Note the functional dependency from m to p: a processor type m uniquely determines the type of the processing context p. Before we move on, consider this canonical item type, which is just a one-field record representing an implementation of the IsItem class: newtype Item m = Item {processItemImpl :: m ()} The corresponding instance declaration is obvious: instance (Monad m) => IsItem m (Item m) where processItem = processItemImpl Furthermore values of every type that is an instance of IsItem can be converted to corresponding Item values: toItem :: (IsItem m i) => i -> Item m toItem = Item . processItem Please stick with me, for we are now going to implement a monad transformer for processors (which, for this example, is really just the identity monad transformer): newtype ProcessorT p m a = ProcessorT {runProcessorT :: m a} instance (Monad m) => Monad (ProcessorT p m) where return = ProcessorT . return ProcessorT m >>= f = ProcessorT (m >>= runProcessorT . f) instance (Monad m) => IsProcessor p (ProcessorT p m) where process = processItem Then, finally, we use this transformer to derive a processor monad: newtype Processor p a = Processor {unwrap :: ProcessorT p Identity a} runProcessor :: Processor p a -> a runProcessor = runIdentity . runProcessorT . unwrap So, we just make sure that Processor is a monad: instance Monad (Processor p) where return = Processor . return Processor m >>= f = Processor (m >>= unwrap . f) Now all what is left to do is declare Processor an instance of IsProcessor. To this end, we need to be able to cast items for Processor p to items for ProcessorT p Identity (for all p). The following function takes care of that: castItem :: (IsItem (Processor p) i) => i -> Item (ProcessorT p Identity) castItem = Item . unwrap . processItem Note that up 'til now everything is fine: GHC is happy, I am happy. But then, when all the hard work is done, and we just only have to connect things properly, it just breaks: instance IsProcessor p (Processor p) where process = Processor . process . castItem After adding this last instance declaration, GHC happily reports: Processor.hs:56:24: Could not deduce (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 Identity))) from the context (IsProcessor p (Processor p), Monad (Processor p), IsItem (Processor p) i) arising from use of `process' at Processor.hs:56:24-30 Probable fix: add (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 Identity))) to the class or instance method `process' or add an instance declaration for (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 Identity))) In the first argument of `(.)', namely `process' In the second argument of `(.)', namely `process . castItem' In the definition of `process': process = Processor . (process . castItem) Processor.hs:56:34: Could not deduce (IsItem (Processor p1) i) from the context (IsProcessor p (Processor p), Monad (Processor p), IsItem (Processor p) i) arising from use of `castItem' at Processor.hs:56:34-41 Probable fix: add (IsItem (Processor p1) i) to the class or instance method `process' or add an instance declaration for (IsItem (Processor p1) i) In the second argument of `(.)', namely `castItem' In the second argument of `(.)', namely `process . castItem' In the definition of `process': process = Processor . (process . castItem) It seems to me that the type checker fails to unify p and p1 where it really should. But once again: I may be wrong here. So, could you either explain to me what I'm missing here and why this program is indeed ill-typed, or confirm that it's really just GHC that should be accepting this program. I have attached a file Processor.hs containing the example program. Please note that I've only tested this with GHC 6.4. I did not try it (yet) with the version in HEAD. Neither did I investigate how Hugs acts on this code. I'm aware that there are some workarounds to get past this problem. The most obvious approach to circumventing this issue is to alter the signature of process so that it takes an explicit Item value and put the need for casting (using toItem) to the caller side. But that's just not the point, of course. I'm sorry for this far too long post, but this issue is quite essential for the code I'm currently working. Reactions, therefore, are much appreciated. TIA, Stefan http://www.cs.uu.nl/~stefan/

1 0

Announce: HSFFIG 1.0 Stable Release
by Dimitry Golubovsky 01 Aug '05

01 Aug '05

Dear List Subscribers, I am pleased to announce the first stable release of HSFFIG, yet another tool for autogeneration of FFI bindings from C include files. The project is now hosted at Sourceforge: http://hsffig.sourceforge.net Downloads page: http://www.sourceforge.net/projects/hsffig Darcs repo: darcs get http://hsffig.sourceforge.net/repos/hsffig-1.0 Tutorial: http://www.haskell.org/hawiki/HsffigTutorial The wiki page "HsffigExamples" has been separated from the Tutorial. If anybody has an interesting example of using HSFFIG please update the page with code samples. Brief summary of changes: - The distribution is now cabalized. Please read the INSTALL file. - The multiparameter class and combinators to access members of structures/unions are moved to separate library. It is necessary to specify -package HSFFIG when compiling applications. Thanks to everybody who participated in discussions related to HSFFIG on this list, and privately. This helped me with implelentation of some features and gave some ideas for future improvement. Debian, RPM, and other packagers: if you create a HSFFIG package please let me know the package URL so I can update the Freshmeat project information page, and the project homepage. For any problems related to this project feel free to contact me. -- Dimitry Golubovsky

1 0

Call for participation: CUFP 2005
by Andy Moran 01 Aug '05

01 Aug '05

IMPORTANT NOTE: Registration is now available at: http://www.cs.ioc.ee/tfp-icfp-gpce05/ CUFP 2005 THE SECOND ACM SIGPLAN COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING WORKSHOP http://www.galois.com/cufp/ Talinn, Estonia September 24th 2005 Co-located with ICFP http://www.brics.dk/~danvy/icfp05/ ---------------------------------------------------------------------- Important dates Early registration deadline July 29, 2005 Late registration deadline September 2, 2005 Workshop September 24, 2005 Registration is available at: http://www.cs.ioc.ee/tfp-icfp-gpce05 ---------------------------------------------------------------------- The goal of CUFP is to build a community for users of functional programming languages and technology, be they using functional languages in their professional lives, in an open source project (other than implementation of functional languages), as a hobby, or any combination thereof. In short: anyone who uses functional programming as a /means/, but not an /end/. ---------------------------------------------------------------------- Schedule The meeting will last a full day, with a mix of invited presentations and discussion sessions. This year, we have the following confirmed speakers: * Atrijus Tang; talking about PUGS, a Perl6 implementation, written in Haskell; * Fabrice Le Fessant; talking about MLDonkey, a popular multi-platform, multi-network P2P client written in OCaml. * Michael Sperber; talking about uses of Scheme in the banking industry. * David Roundy; talking about darcs, a popular and flexible revision control system well-suited to highly distributed development, written in Haskell. * Jim Grundy; talking his experiences with functional programming at Intel's Strategic CAD Labs. * Robert Boone; talking about his experiences at FreeScale. * Jonathan Soebel; talking about lessons the FP community can learn from the OMG's Model Driven Architecture (MDA) and its related marketing efforts. We will also be having two working sessions, where lively debate and brainstorming will be the order of the day: * FP, Education, and Industry: industry folks complain that there aren't enough FP folks being produced by schools, and educators complain that students don't see any point in studying FP if there are no jobs to be had. How can we break this stalemate? Simon Thompson of Functional and Declarative Programming in Education (FDPE05) will be joining us, and we'll be debriefing at FDPE05. * Stimulating a CUFP Community: we'd like the buzz and excitement surrounding CUFP to persist beyond the workshops. What would such a community look like? How do we make it happen? The session will kick off with two separate but complimentary starting points: a proposed "Users of FP" community web site and a proposed "Haskell Consortium" web site. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. A full report of last year's workshop appeared in the Functional Programming column of the December 2004 issue of SIGPLAN Notices, and we plan to do the same this year. -- Andy Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran(a)galois.com

5 6

STM and MonadFix?
by Jonathan Cast 29 Jul '05

29 Jul '05

Why is there no MonadFix STM instance? Jon Cast

1 0

RE: [Haskell-cafe] hssfig: Unresolved symbols when importing a foreignlibrary: what is the preferred way of handling?
by Simon Marlow 28 Jul '05

28 Jul '05

On 27 July 2005 15:32, Dimitry Golubovsky wrote: > - instead of generation of a single object file referencing all the > functions, create one per funciton import and place them all in an > archive (.a). Then, when linking, only actually used functions will be > picked from the archive. This is what ghc -split-objs does. It's something of a hack, but I just thought I'd mention it. I believe it would fix your problem. Cheers, Simon

1 0

Suggestions for #defines with FFI
by John Goerzen 28 Jul '05

28 Jul '05

Hi, I'm writing a Haskell interface to a library that #defines about 100 constants corresponding to numeric exit codes. It also defines hundreds of contants, over the same numbering ranges, for other purposes. The exit codes are non-contiguous as well. So my question is: is there a nice way I can represent this in Haskell, preferably without having to key in all 100 constants? Or will I just have to list all the options and give up type checking to differentiate one purpose of a constant from another? Thanks, -- John

3 3

RE: [Haskell-cafe] Suggestions for #defines with FFI
by Dimitry Golubovsky 28 Jul '05

28 Jul '05

John, Could you please give an example of such constant definitions? Is it possible to look at the include file? -- Dimitry Golubovsky Anywhere on the Web

4 5

hssfig: Unresolved symbols when importing a foreign library: what is the preferred way of handling?
by Dimitry Golubovsky 27 Jul '05

27 Jul '05

I would like to collect opinions from interested people on this matter. Background: Hsffig parses include files (.h) and generates FFI import declarations for every function/external variable it encounters a prototype declaration for. The result is a .hsc file which is converted into a Haskell source and compiled into an object file and linked into an executable along with other application source files using ghc as frontend (so far, hsffig is targeted to ghc users only). This object file will contain references to all foreign functions to be imported. Problem: In some cases, a include file may contain prototypes of functions not existing in the library it corresponds to. In my case, <unistd.h> (Linux, glibc2) contains prototypes for __ftruncate and pthread_atfork which come up unresolved when linking the executable without additional libraries specified. pthread_atfork is resolved when linking with -lpthread. Where is __ftruncate defined, I don't know, and I do not really want ot know unless I need to use this function. Possible solutions, sorted by expected amount of work necessary to implement (please pick one you would prefer, or suggest yours): - leave everything as is: the executable will not be linked until the developer finds all the libraries to resolve all the missing symbols. That's how it works (or doesn't work) now. - tell ld only to warn about unresolved symbols: the executable will be built anyway, but if the unresolved function is called from under the hood it most likely results in segfault hard to explain (which function caused it). Only special linker option is required. - for each foreign function imported, generate a stub which, when called, complains loudly and aborts the program. These stubs are placed in a separate object file and linked after all possible libraries, so library-defined symbols always take precedence. The disadvantage is: the developer would not know which symbols remained unresolved when the executable was linked, only will he know when the application crashes. I am trying to implement this now, using the hsc2hs' #def macro to define those stub functions. - analyze the linker output and make auto-correction in the generated .hsc file just by excluding FFI declarations for unresolved functions. Non-elegant, requires second pass and highly platform and tool dependent. - instead of generation of a single object file referencing all the functions, create one per funciton import and place them all in an archive (.a). Then, when linking, only actually used functions will be picked from the archive. I am not sure how would this interact with ghc --make: I got an impression that a .hi file is necessary for all modules (.hs/.hi/.o triple) imported unless they are gotten from a package. If I have in my program: import FOO_H and there is no FOO_H.hi nor FOO_H.hs, only libFOO_H.a: how ghc would live with this? The latter approach does not take much to implement in hsffig itself (I already have a splitter which splits into one object file per a structure/union). I am more concerned how to make ghc live with this. Creation of a package for each imported include file seems like overkill. PS I believe that hsffig will be an useful utility. I noticed several people downloaded nightly tarballs or checked out from the DARCS repo. If these persons have found this program useful, would they please suggest something on the matter I described. -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: [Haskell-cafe] ForeignPtrs with liveness dependencies
by Simon Marlow 27 Jul '05

27 Jul '05

On 26 July 2005 16:49, Einar Karttunen wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> No, unfortunately not. You have foo's finalizer which refers to bar >> via a touchForeignPtr. If both foo and bar are unreachable >> (references from finalizers don't count), then both foo and bar's >> finalizers will be started together, and may run in any order. > > I didn't realize the "references from finalizers don't count" rule. It does make sense. If references from finalizers *did* keep objects alive, then if you had two objects that referreed to each other by their finalizers, neither would ever be finalized. This paper has all the rationale, you might find it interesting: http://www.haskell.org/~simonmar/papers/weak.pdf Expressing ordering relationships between finalizers is known to be hard - for instance, if you have a chain of N dependent finalizers that are all unreachable, you don't want to take N major GCs to discover the fact. The canonical paper on this is Hans Boehm's "Destructors, finalizers, and synchronization": http://portal.acm.org/citation.cfm?id=604153 > What would happen if the finalizer of foo would resurrect bar after > bar's finalizer has been run? That can happen. Nothing goes wrong on the Haskell side, but if this is a problem for your C objects then you need to be aware of it. >> So touchForeignPtr does only one thing: it expresses the precise >> relationship "bar is alive if foo is alive". If both are not alive, >> then both finalizers can run, in any order. > > So reference counting the objects is the solution? Perhaps. It seems robust, anyway. >> I realise this is very subtle. By all means suggest improvements to >> the docs. > > Mentioning that references from finalizers don't count could help > someone not to repeat my mistakes. Ok, will do. Cheers, Simon

1 0

Newbie question about Read strings in a line of File
by Huong Nguyen 26 Jul '05

26 Jul '05

Hello everybody, Now I am writing a module to handles messages of a system. The messages are stored in a file. The content of each line of the file likes this: 1 001 001 Error message 1 1 001 002 Error message 2 1 002 001 Warning message 1 in which: The first word is the language Code (e.g: 1 is English, 2 is French), the second is type of messages (e.g: 001 is error message, 002 is warning message,etc), the third is the index number of messages, and the last is the message. I need to read 3 first words of each line and assign them to 3 variables. After that, I need to show the error message based on the tuple of those 3 first variable, e.g: errMsg("1","001","001") = "Error message 1" At first, I tried to read only one first line of the file as follows: import Prelude import List import Char import IO main = do hdl <- openFile "message.txt" ReadMode msgLine <-hGetLine hdl --stdMsg: cut space at the begining of the line. let stdMsg = dropWhile(not.isSpace) msgLine -Assign langCode with the first word of the line. let langCode = takeWhile(not.isSpace) stdMsg However, after that, I do not know how to read second element, third element of the line. And how to read continuous next line after first? Please help me. Thanks a lot.

2 1

RE: [Haskell-cafe] ForeignPtrs with liveness dependencies
by Simon Marlow 26 Jul '05

26 Jul '05

On 26 July 2005 14:15, Einar Karttunen wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >>> Now the association becomes >>> associate (Foo _ ref) bar = >>> atomicModifyIORef ref (\lst -> (touchForeignPtr bar : lst, ())) >> >> Isn't that equivalent to using addForeignPtrFinalizer? I don't think >> this fixes anything: the finalizer for bar can still run before the >> finalizer for foo. > > foo has a single finalizer which is defined like: > > fooFinalizer cfoo ref = do cdeleteFoo cfoo > vs <- readIORef ref > mapM_ (\c -> c) vs the last line is equivalent to "sequence_ vs", FWIW. > and foo is created like > > createFoo ptr = do ref <- newIORef [] > fp <- newForeigPtr ptr (fooFinalizer ptr ref) > return (Foo fp ref) > > As the finalizer of foo references the IORef which contains > the list of actions containing the "touchForeignPtr bar" > the finalizer of foo is run first. The finalizer to bar > should be able to run only when the touchForeignPtr has been > executed in the mapM_ which only happens after foo > has been cleaned up - if I understand things correctly. No, unfortunately not. You have foo's finalizer which refers to bar via a touchForeignPtr. If both foo and bar are unreachable (references from finalizers don't count), then both foo and bar's finalizers will be started together, and may run in any order. So touchForeignPtr does only one thing: it expresses the precise relationship "bar is alive if foo is alive". If both are not alive, then both finalizers can run, in any order. I realise this is very subtle. By all means suggest improvements to the docs. Cheers, Simon

2 1

Data-types in dynamically loaded hs-plugins
by Thomas Sutton 26 Jul '05

26 Jul '05

Hi all, I'm [trying to] develop a system that uses plug-ins to implement a "black-box" ADT, that is a data-type and a few typeclass instances for it. I want my system (a theorem prover) to be able to work with any of these plug-ins (which define a logic and operations on its formulae) but have been having trouble. I've had a go at using forall's, and at adding a type variable (constrained to the appropriate class) to the interface of the plug- in, but I haven't been able to get it to work and have run out of ideas. Is it possible to define data-types in a module loaded at run-time with hs-plugins and have values pass out of the plug-in (though only being used by functions within it)? Can someone point me in the right direction? Cheers, Thomas Sutton

1 0

RE: [Haskell-cafe] ForeignPtrs with liveness dependencies
by Simon Marlow 26 Jul '05

26 Jul '05

On 26 July 2005 11:26, Einar Karttunen wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> You might be able to find more information on this in the mailing >> list archives. It's true that touchForeignPtr isn't enough to >> enforce an ordering on the running of finalizers, but it *can* be >> used to express a liveness relationship between one ForeignPtr and >> another (ForeignPtr A is alive if ForeignPtr B is alive). This >> should be enough if you're dealing with pointer relationships >> between memory objects, for example, where it doesn't matter which >> one gets freed first when they're both unreferenced. > > The order of the cleanup functions is significant in this case, > so that does not unfortunately help. > >> If you really do need ordering, maybe it would be possible to use >> reference counting in your case? > > I ended up using the following design, which seems to work fine: > data Foo = Foo (ForeignPtr Foo) (IORef [IO ()]) > Each ForeignPtr Foo has a single finalizer which first calls the > C-side cleanup function for Foo and then executes all the IO-actions > inside the IORef. > > Now the association becomes > associate (Foo _ ref) bar = > atomicModifyIORef ref (\lst -> (touchForeignPtr bar : lst, ())) Isn't that equivalent to using addForeignPtrFinalizer? I don't think this fixes anything: the finalizer for bar can still run before the finalizer for foo. Cheers, Simon

2 1

RE: [Haskell-cafe] FFI and callbacks
by Simon Marlow 26 Jul '05

26 Jul '05

On 26 July 2005 11:32, Sebastian Sylvan wrote: > On 7/26/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> On 25 July 2005 22:41, Sebastian Sylvan wrote: >>> Well how about not touching the "bound threads" design at all, but >>> modifying the lightweigh threads design to also include "forkIOHere" >>> (or something) which would produce a lightweight thread which is >>> always run in the "main" OS thread. >> >> This is what Duncan was angling for, I think. My point is that this >> requires the implementation to support lightweight threads, which is >> something we intentionally avoided in the bound threads design. > > No it doesn't. If they don't support lightweight threads, they won't > have the forkIOHere function available. > I.e. leave it out of the bound threads design and just implement it as > a feature in the GHC lightweight threads system. I think you misunderstand me. I'm merely pointing out that the fact that it would be a GHC-specific feature is a drawback. (not that any other compilers have bound threads either, but still). Cheers, Simon

1 0

RE: [Haskell-cafe] FFI and callbacks
by Simon Marlow 26 Jul '05

26 Jul '05

On 25 July 2005 22:41, Sebastian Sylvan wrote: > On 7/25/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> On 23 July 2005 03:38, Duncan Coutts wrote: >> >>> The problem then as John noted is that the main loop of these >>> toolkits block and so the other Haskell threads would not get a >>> chance to schedule. So the challenge is to give the Haskell threads >>> a chance to schedule. >> >> [ good description of the multi-threaded GUI problem deleted ] >> >> Thanks for describing the problem in detail, I understand it better >> now. I think it comes down to this conflict: >> >> - you want to take advantage of the fact that GHC has lightweight >> "green" threads in order to do multithreading within a single OS >> thread, but >> >> - our "bound threads" design does not require the implementation >> to support lightweight threads, and hence doesn't let the >> programmer take advantage of them. > > Well how about not touching the "bound threads" design at all, but > modifying the lightweigh threads design to also include "forkIOHere" > (or something) which would produce a lightweight thread which is > always run in the "main" OS thread. This is what Duncan was angling for, I think. My point is that this requires the implementation to support lightweight threads, which is something we intentionally avoided in the bound threads design. While I don't doubt that we could implement some way to fork another thread bound to the same OS thread as the parent, I'm worried that this would add yet more complexity to GHC's scheduler, so I think we should fully explore other possibilities first. Cheers, Simon

2 1

RE: [Haskell-cafe] ForeignPtrs with liveness dependencies
by Simon Marlow 26 Jul '05

26 Jul '05

On 25 July 2005 14:44, Einar Karttunen wrote: > What is the correct way to express liveness dependencies for > ForeignPtrs? I am wrapping a C library and need a way to keep > ForeignPtrs alive until the finalizer for an another ForeignPtr > has been executed. > > Basically I have two types, ForeignPtr A and ForeignPtr B and a > function associate :: ForeignPtr A -> ForeignPtr B -> IO (). I want > to keep all of the ForeignPtr Bs associated with a given ForeignPtr A > alive until its finalizer has been run. The relationship is M:N - > each ForeignPtr A may be associated with multiple ForeignPtr B and > each ForeignPtr B may be associated with multiple ForeignPtr A. > > GHC documentation tells that touchForeignPtr is not enough as it makes > no guarantees about when the finalizers are run. If it helps the > finalizers are C functions which neither block nor perform callbacks > into Haskell. You might be able to find more information on this in the mailing list archives. It's true that touchForeignPtr isn't enough to enforce an ordering on the running of finalizers, but it *can* be used to express a liveness relationship between one ForeignPtr and another (ForeignPtr A is alive if ForeignPtr B is alive). This should be enough if you're dealing with pointer relationships between memory objects, for example, where it doesn't matter which one gets freed first when they're both unreferenced. If you really do need ordering, maybe it would be possible to use reference counting in your case? Cheers, Simon

2 1

RE: [Haskell-cafe] building Ghc with msvc ?
by Simon Marlow 26 Jul '05

26 Jul '05

On 23 July 2005 22:52, Duncan Coutts wrote: > On Sat, 2005-07-23 at 22:49 +0200, Jan Scott wrote: >> Hi, >> >> Has anyone ever tried to build Ghc with Microsofts c compiler (msvc) >> ? > > GHC relies quite heavily on gcc. GHC's C code backend uses a number of > GNU C extensions I believe. > > I think it would be a great deal of work to make it use msvc. And > there's no need since the mingw gcc works just fine on windows and is > binary compatible with msvc (if one uses the appropriate gcc options). I'd like to make the native code generator produce code in Intel syntax so it would be possible to use the MS binutils as an alterntiave to the GNU tools (the MS tools are available for free). Playing nicely with native Windows debuggers would be useful for debugging mixed Haskell/foreign language apps, I've had no end of trouble trying to use gdb for this. I believe the C parts of the RTS has been (is?) compilable with MSVC. The non-C parts of the RTS still need ghc -fvia-C (ie. gcc), but if I ever get around to adding support for loops in the native code generator we could drop that dependency too. I seriously doubt that we'd add support to the mangler for the Intel asm syntax, but generating Intel asm with the NCG is a distinct possibility. Cheers, Simon

1 0

Control.Monad.Cont fun
by oleg＠pobox.com 26 Jul '05

26 Jul '05

On Thu, Jul 07, 2005 at 07:08:23PM +0200, Tomasz Zielonka wrote: > Some time ago I wanted to return the escape continuation out of the > callCC block, like this: > > getCC = callCC (\c -> return c) It seems using shift/reset is better not only in principle but in practice as well. > module Foo where > > import Control.Monad.Cont > > -- From http://www.haskell.org/hawiki/MonadCont > reset :: (Monad m) => ContT a m a -> ContT r m a > reset e = ContT $ \k -> runContT e return >>= k > > shift :: (Monad m) => > ((a -> ContT r m b) -> ContT b m b) > -> ContT b m a > shift e = ContT $ \k -> > runContT (e $ \v -> ContT $ \c -> k v >>= c) return We can define a more general getCC' form simply as follows: > getCC' init = shift (\f -> f (init,jump f)) > where jump f x = f (x,jump f) The compiler figures out the types. Here's the usage example from the original Tomasz's message > test1' :: IO () > test1' = (`runContT` return) $ > do > reset (do > (x, jump) <- getCC' 0 > lift (print x) > when (x < 10) $ jump (x + 1)) > lift (putStrLn "finish") That was using the ContT monad exactly as it comes with GHC 6.4. With the CC_CPST monad transformer (with multiple polymorphic prompts) we can do better: > getCCP' p init = shiftP p (\f -> f (return (init,jump f))) > where jump f x = f (return (x,jump f)) The following code (written a couple of weeks) prints 1 through 10, then again 4 through 10 and then again 5 through 10, and then "finish". So we can not only note a label to jump to: we can return the label so to jump to it from different `functions'. In a sense, we emulate multiple entry points to a block and cross-block jumps. > test1'' :: IO () > test1'' = runCC ( > do > p <- newPrompt > p1 <- newPrompt > j <- pushPrompt p1 ( pushPrompt p ( > do > (x, jump) <- getCCP' p 0 > lift (print x) > when (x < 10) $ jump (x+1) > shiftP p1 (const (return jump))) >> undefined) > lift (putStrLn "again") > pushPrompt p1 (j 4 >> undefined) > lift (putStrLn "and again") > pushPrompt p1 (j 5 >> undefined) > lift (putStrLn "finish")) In this terminating code, undefined plays a great role.

1 0

Control.Monad.Cont fun
by Tomasz Zielonka 26 Jul '05

26 Jul '05

Hello! Some time ago I wanted to return the escape continuation out of the callCC block, like this: getCC = callCC (\c -> return c) But of course this wouldn't compile. I thought that it would be useful to be able to keep the current continuation and resume it later, like you can in do in scheme. Well, it was easy to do this in Haskell in the (ContT r IO) monad, by using an IORef. But I wasn't able to solve this for all MonadCont monads. After more then year of on-and-off trials, I've finally managed to do this! ;-) import Control.Monad.Cont getCC :: MonadCont m => m (m a) getCC = callCC (\c -> let x = c x in return x) getCC' :: MonadCont m => a -> m (a, a -> m b) getCC' x0 = callCC (\c -> let f x = c (x, f) in return (x0, f)) getCC allows to set a backward "goto label". Here's an example: -- prints "hello!" in an endless loop test :: IO () test = (`runContT` return) $ do jump <- getCC lift (putStrLn "hello!") jump getCC' allows to jump back with arguments: -- prints integers from 0 to 10, then prints finish and ends test' :: IO () test' = (`runContT` return) $ do (x, jumpWith) <- getCC' 0 lift (print x) when (x < 10) (jumpWith (x + 1)) lift (putStrLn "finish") I think this is rather cool! :-) Besides sharing my happiness, I want to ask some questions: - what would be the best names for these functions - is it possible to define a MonadFix instance for Cont / ContT? - do you think it would be a good idea to add them to Control.Monad.Cont? Best regards Tomasz

5 10

RE: [Haskell-cafe] FFI and callbacks
by Simon Marlow 25 Jul '05

25 Jul '05

On 23 July 2005 03:38, Duncan Coutts wrote: > The problem then as John noted is that the main loop of these toolkits > block and so the other Haskell threads would not get a chance to > schedule. So the challenge is to give the Haskell threads a chance to > schedule. [ good description of the multi-threaded GUI problem deleted ] Thanks for describing the problem in detail, I understand it better now. I think it comes down to this conflict: - you want to take advantage of the fact that GHC has lightweight "green" threads in order to do multithreading within a single OS thread, but - our "bound threads" design does not require the implementation to support lightweight threads, and hence doesn't let the programmer take advantage of them. When we were thinking about bound threads, the idea was to accommodate multiple implementations including the one-to-one and giant lock approaches. We consider(ed) GHC's mixture of lightweight and heavyweight threads to be an optimisation. However, the GUI library example is interesting, because if we could take advantage of lightweight threads it seems we could have multithreaded access to the GUI with better performance and no requirement to make all GUI calls from a single thread. But I'm not convinced. There are advantages to using the single GUI thread approach, and we don't have any measurements for whether the overhead is too much. Suppose you set up a channel containing requests of type (IO a, MVar a), where the MVar takes the result. You can build a combinator withGUI :: IO a -> IO a to perform a GUI operation (and this allows you to try multiple approaches without changing the code). Using withGUI you can send a whole batch of GUI operations in one go, it doesn't have to be one request per GUI call. You could also build asyncGUI :: IO a -> IO () which fires off a GUI request that doesn't require a result, and combines it with existing requests in a single batch if possible. Ordering would be retained, of course. The GUI thread will run multiple requests sequentially, it doesn't have to context switch between each request. And you get more parallelism, because the other threads continue to run while the GUI thread is in the main loop. Cheers, Simon

4 5

Updating the Haskell Standard
by John Goerzen 25 Jul '05

25 Jul '05

There was a brief discussion on #haskell today about the Haskell standard. I'd like to get opinions from more people, and ask if there is any effort being done in this direction presently. I think an updated standard is overdue. I find it difficult anymore to write any but the most trivial of programs using pure Haskell 98. Some notable, and widely-used, features developed since then include: * Overlapping instances * FFI * Hierarchical namespace * Undecidable instances * All sorts of updates to the standard library It has been awhile since I wrote a Haskell program that can compile in pure Haskell 98 mode. I think it would benefit everyone if a more up-to-date standard were made available. I know that some people would like to hold off on such a process until their favorite feature (we'll call it feature X) is finished. I would argue that incremental addendums to the standard should be made more frequently, so that new features can be standardized more easily. Thoughts? Who organized the standardization effort last time?

10 11

ForeignPtrs with liveness dependencies
by Einar Karttunen 25 Jul '05

25 Jul '05

Hello What is the correct way to express liveness dependencies for ForeignPtrs? I am wrapping a C library and need a way to keep ForeignPtrs alive until the finalizer for an another ForeignPtr has been executed. Basically I have two types, ForeignPtr A and ForeignPtr B and a function associate :: ForeignPtr A -> ForeignPtr B -> IO (). I want to keep all of the ForeignPtr Bs associated with a given ForeignPtr A alive until its finalizer has been run. The relationship is M:N - each ForeignPtr A may be associated with multiple ForeignPtr B and each ForeignPtr B may be associated with multiple ForeignPtr A. GHC documentation tells that touchForeignPtr is not enough as it makes no guarantees about when the finalizers are run. If it helps the finalizers are C functions which neither block nor perform callbacks into Haskell. - Einar Karttunen

1 0