December 2006 - Haskell

What guarantees (if any) do interruptible operations have in presence of asynchronous exceptions?
by Cat Dancer 05 Dec '06

05 Dec '06

>From the discussion of "Help needed interrupting accepting a network connection", what we have so far is: * To break out of an "accept" call, an asynchronous exception is needed. * The presence of asynchronous exceptions complicates the other code used to report if "accept" completed or was interrupted, whether that code is written using MVar's or STM. Thus the next question is what guarantees, if any, do interruptible operations possess? For example, suppose that inside of a "block", a putMVar operation was guaranteed to either interrupt and allow an asynchronous exception to be raised, or to complete the putMVar operation, but not both. If this were true, then if you caught an asynchronous exception from the putMVar operation, you'd know that a value was not put into the MVar by the operation. Then it would be easy to program with MVar's in the presence of asynchronous exceptions. When you caught an asynchronous exception, you could set a flag, and then redo the putMVar. The same question can be asked of other interruptible operations. For the "accept" call itself, is it guaranteed (inside of a "block") to either accept a connection, or be interrupted and allow an asynchronous exception to be raised, but not both? For STM, is "atomically" an interruptible operation? If it is, what guarantees does it offer in the presence of asynchronous exceptions?

2 3

Safe forking question
by Chris Kuklewicz 05 Dec '06

05 Dec '06

In response to question by Cat Dancer <cat(a)catdancer.ws> I wrote a few tests of sending asynchronous signal to a thread using GHC 6.6 The goal was to run a child thread via forkIO and use handle or finally to respond to the thread's demise. Unfortunately, it seems that there is an irreducible window where this fails. The forkIO returns but any exception handlers such as block/handle/catch/finally are not in place yet. So this fails: > module Main where > > import Control.Exception > import Control.Concurrent > import Control.Concurrent.STM > > forever x = x >> forever x > > count tv = do > val <- takeTMVar tv > putTMVar tv $! (succ val) > return val > > -- Capture idiom of notifying a new MVar when a thread is finished > fork todo = do > doneMVar <- newEmptyMVar > tid <- block $ forkIO $ block $ handle (\e -> print ("Exception",e) >> throw e) > (finally (unblock todo) > (print "dying!" >> putMVar doneMVar ())) > return (doneMVar,tid) > > spawn = do > tv <- atomically (newTMVar 0) > fork . forever $ atomically (count tv) >>= print > > kill (mv,tid) = do > -- yield > print "killing.." > killThread tid > print "..checking corpse.." > readMVar mv > print "..confirmed dead" > > main = spawn >>= kill On my system, the above sends the killThread and destroys the thread before the handle or finally are setup, so the child thread never prints anything and never runs the "putMVar doneMVar ()". If I uncomment the yield statement then the child thread does start executing and the handle and finally work as desired. This makes it impossible to reliably do anything with the child thread. I cannot discern between a living and dead child thread at all, as there is way to know if it is waiting to be scheduled or if it has been killed waiting to be scheduled. The get/setUncaughtExceptionHandler does not seem to be inherited by the child thread, so this was not a useful guard. The best thing I can come up with is the ugly code: > fork todo = block $ do > doneVar <- atomically (newEmptyTMVar) > let putStarted = atomically (putTMVar doneVar False) > putStopped = atomically (tryTakeTMVar doneVar >> putTMVar doneVar True) > tid <- forkIO $ block $ (finally (putStarted >> unblock todo) putStopped) > yield > atomically $ do > value <- takeTMVar doneVar > when value (putTMVar doneVar True) > return (doneVar,tid) This does not return the ThreadId until the finally clause has started running. But if the thread is killed by any external force before getting that far then the main thread will hang on the "takeTMVar doneVar". Is there any remotely better way of forking a child with an exception handler? -- Chris

3 5

How to use STM in GUI applications?
by Thorsten Seitz 05 Dec '06

05 Dec '06

Hello, I'm very intrigued by the concepts of STM but I'm having difficulties to see how a TVar based model can be used by a GUI application (e.g. Gtk2hs): For example, I'd like to update the GUI (e.g. changing widget sensitivity) upon changes in the model. But changing the sensitivity of a widget is an IO operation which cannot be initiated atomically by a model change which is an STM operation. Therefore the GUI change cannot be executed atomically together with the model change. This means for example that I can still press a button although the model has changed such that the button action is not allowed anymore. All I can do is check the condition of the model when the button is pressed and then ignore the button press which is not very satisfying for the user. Is it simply not appropriate to use TVar based models in a GUI application? Maybe STM should be more used like a service for MVar based GUI models? Thanks for any help! -Thorsten

3 2

Haskell Weekly News: December 05, 2006
by dons＠cse.unsw.edu.au 05 Dec '06

05 Dec '06

--------------------------------------------------------------------------- Haskell Weekly News http://haskell.org/haskellwiki/HWN Issue 52 - December 05, 2006 --------------------------------------------------------------------------- Welcome to issue 52 of HWN, a weekly newsletter covering developments in the Haskell community. This week we see the 11th Haskell Communities and Activities Report released, Visual Haskell 0.2 is available, and a suite of new libraries and applications are announced. Announcements Communities and Activities Report. Andres Loeh [1]published the [2]Haskell Communities and Activities Report (11th edition, November 2006). The report is now available from the Haskell Communities home page in several formats. The goal of the report is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. 1. http://article.gmane.org/gmane.comp.lang.haskell.general/14545 2. http://www.haskell.org/communities/ Visual Haskell prerelease 0.2. Krasimir Angelov [3]announced that there is a prerelease version of Visual Haskell [4]available. This is the first version that is: available for both VStudio 2003 and VStudio 2005, and distributed with a stable GHC version (6.6) 3. http://thread.gmane.org/gmane.comp.lang.haskell.general/14527/focus=14527 4. http://www.haskell.org/visualhaskell Haskell MIME library. Jeremy Shaw [5]announced the availability of a MIME processing library. This library is supposed to be able to parse emails and decode various attachments, and generate emails with attachments. [6]The library includes modules that implement portions of: RFC 2045, RFC 2046, RFC 2387 and RFC 2822. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/14555 6. http://www.n-heptane.com/nhlab/repos/haskell-mime Core (ghc-base) library. Bulat Ziganshin [7]announced progress on the Core library project, to divide the Haskell base library into two parts: small compiler-specific one (the Core library proper) and the rest: new, compiler-independent Base library that uses only services provided by Core lib. 7. http://article.gmane.org/gmane.comp.lang.haskell.general/14546 hpodder 0.99.0. John Goerzen [8]announced hpodder 0.99.0, the first beta candidate for making an eventual 1.0.0 release of hpodder. [9]hpodder is a podcast downloader that happens to be written in Haskell. This version introduces two major new features: nicer apt-like output and multithreaded downloading. 8. http://article.gmane.org/gmane.comp.lang.haskell.general/14533/ 9. http://quux.org/devel/hpodder MissingH 0.16.3. John Goerzen [10]released MissingH 0.16.3. Including a new module MissingH.ProgressTracker which tracks the progress of long-running tasks, and MissingH.Quantity which renders numbers according to a quantification system such as SI or binary. 10. http://article.gmane.org/gmane.comp.lang.haskell.general/14532 The restricted IO monad. Stefan O'Rear [11]introduced RIO, an experimental library for extensible restricted IO in Haskell. 11. http://article.gmane.org/gmane.comp.lang.haskell.general/14526 Typed symbolic differentiation. Oleg Kiselyov [12]showed symbolic differentiation of a wide class of numeric functions without any interpretative overhead. The functions to symbolically differentiate can be given to us in a compiled form (in .hi files); their source code is not needed. We produce a (compiled, if needed) function that is an exact, algebraically simplified analytic derivative of the given function. Our approach is reifying code into its `dictionary view', intensional analysis of typed code expressions, and the use of staging to evaluate under lambda. 12. http://article.gmane.org/gmane.comp.lang.haskell.general/14566 Haskell' This section covers the [13]Haskell' standardisation process. * [14]Standard (core) libraries initiative: rationale * [15]Character literal question 13. http://hackage.haskell.org/trac/haskell-prime 14. http://article.gmane.org/gmane.comp.lang.haskell.prime/1919 15. http://article.gmane.org/gmane.comp.lang.haskell.prime/1942 Libraries This week's proposals and extensions to the [16]standard libraries. * [17]Data.List documentation improvements 16. http://haskell.org/haskellwiki/Library_submissions 17. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/5902/focus=5902 Discussion The Data.Array.* hierarchy is unsafe: segfaulting for fun and profit. Spencer Janssen [18]revealed that a malicious Ix instance can be used to create segfaulting array programs in pure Haskell (under GHC or Hugs), without the use of anything marked 'unsafe'. The array operators trust the Ix instance to manage boundaries correctly. It was pointed out that the Haskell standard requires Ix instances obey an in-range side condition (just as Monad instances have side conditions). 18. http://article.gmane.org/gmane.comp.lang.haskell.libraries/5903/ Merging MissingH into the standard libraries. John Goerzen [19]proposed a [20]renaming plan to aid splitting, and merging the various MissingH modules into their own packages, and into base 19. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/16985/focus=16985 20. http://software.complete.org/missingh/wiki/TransitionPlanning Defining Cg, HLSL style vectors in Haskell. Slavomir Kaslev [21]asked about defining a couple of float2, float3, float4 Cg, HLSL style vectors in Haskell. 21. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/16898/focus=16898 Extracting sublists. Huazhi Gong [22]asked about the best way to extract sublists. Several solutions where suggested, including [23]a nice one by Oleg. 22. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/16976/focus=16976 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/16984 Generating 50 randoms. Huazhi Gong [24]also asked about how best to generate 50 random integers, leading to some lovely of creative writing... 24. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/17029/focus=17029 Blog noise [25]Haskell news from the blogosphere. * [26]Haskell Preliminaries: Implementations and Tools * [27]Simple Functions in Haskell * [28]Functions, Types, Function Types, and Type Inference * [29]Building Datatypes in Haskell (part 1) * [30]OOPSLA 2006 Summary * [31]Some Very Basic Haskell and Thoughts on Error Diagnosis * [32]Hello world! in Haskell * [33]Haskell - A valuable language * [34]On Functional Programming * [35]Listing files in Haskell * [36]Bits and Pieces of Haskell * [37]Typing like a Functional Programmer * [38]6 Languages * [39]Closures and bottom for Java * [40]A newbie in Haskell land * [41]Interesting parsers in Haskell * [42]Meep for developers (finite-difference time-domain simulation software in Haskell) * [43]Algorithmic Music in Real Time using Haskell * [44]Rank-2 polymorphism is a strange thing * [45]Scalable computer programming languages * [46]Parser with Writer monad * [47]Metacognitive processes involved in deriving a solution to unzip * [48]Python Decorators - not desirable in Haskell * [49]Tools for haskell problem solving * [50]Technology Time Warp: trying out Lisp and Haskell * [51]Haskell programming language assignment * [52]Building GHC in under 10 minutes * [53]Lets play a game * [54]foldr, foldl * [55]Monads in Ruby Part 1: Identity * [56]Monads In Ruby Part 1.5: Identity * [57]New Languages * [58]You have to love Haskell * [59]Polynomials as numbers * [60]Parser combinators * [61]Lisp, you're old (but we love you anyway) * [62]Will somebody please think of the Parens!? * [63]Diving into Haskell * [64]FourFours in Haskell 25. http://planet.haskell.org/ 26. http://scienceblogs.com/goodmath/2006/11/haskell_preliminaries_implemen.php 27. http://scienceblogs.com/goodmath/2006/11/simple_functions_in_haskell_1.php 28. http://scienceblogs.com/goodmath/2006/12/functions_types_function_types_1.p… 29. http://scienceblogs.com/goodmath/2006/12/building_datatypes_in_haskell_1.php 30. http://mark.santaniello.net/archives/274 31. http://praisecurseandrecurse.blogspot.com/2006/11/some-very-basic-haskell-a… 32. http://blog.milkfarmsoft.com/?cat=6 33. http://channel9.msdn.com/ShowPost.aspx?PostID=261386#261386 34. http://www.pbell.com/index.cfm/2006/11/26/On-Functional-Programming 35. http://therning.org/magnus/archives/228 36. http://pseudofish.com/blog/2006/11/28/bits-and-pieces-of-haskell/ 37. http://www.artima.com/weblogs/viewpost.jsp?thread=186200 38. http://sharp-blue.livejournal.com/14234.html 39. http://www.javac.info/closures-v03.html 40. http://www.alpheccar.org/en/posts/show/60 41. http://www-etud.iro.umontreal.ca/~laurieti/parser.html 42. http://shejun.blogspot.com/2006/11/meep-for-developers.html 43. http://hemiolesque.blogspot.com/2006/11/algorithmic-music-in-real-time.html 44. http://cucumariid.livejournal.com/36757.html 45. http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programm… 46. http://sequence.complete.org/node/231 47. http://sequence.complete.org/node/235 48. http://sequence.complete.org/node/232 49. http://sequence.complete.org/node/230 50. http://markagrant.blogspot.com/2006/12/technology-time-warp.html 51. http://ched.vox.com/library/photo/6a00c225264de2549d00cdf3a3d6fbcb8f.html#c… 52. http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/03#build_ghc_fast 53. http://e-scribe.com/news/193#541 54. http://monad.carnalreason.org/wordpress/?p=19 55. http://meta-meta.blogspot.com/2006/12/monads-in-ruby-part-1-identity.html 56. http://meta-meta.blogspot.com/2006/12/monads-in-ruby-part-15-identity.html 57. http://www.travishartwell.net/blog/2006/12/02_1144 58. http://mikepence.wordpress.com/2006/10/31/you-have-to-love-haskell/ 59. http://www.quetzal.com/sambangu/2006/12/polynomials-as-numbers 60. http://a-preponderance-of-pondering.blogspot.com/2006/12/parser-combinators… 61. http://a-preponderance-of-pondering.blogspot.com/2006/12/lisp-youre-old-but… 62. http://foldr.org/~michaelw/log/programming/lisp/lispin 63. http://dm.zimmer428.net/index.php/archives/203 64. http://www.joachim-breitner.de/blog/archives/210-FourFours-in-Haskell.html Quotes of the Week * Andreas Rossberg: To the functional programmer's eye a loop is just a degenerate form of linear recursion written in an adhoc special syntax. * Cale: [on the discovery of a secret pi calculus monad] Someone apparently wasn't informed that integration into the collective Haskell hive-mind is mandatory * secretgeek: Because we've reached the limits of Moore's Law, the computers of the future will have many-core processors and all our programs will need to be written in a combination of Haskell and Lisp, that will itself be so powerful that the computers of the future will not be able to implement any of our ideas without creating time-travelling algorithms that borrow processing power from other computers that are further into the future. This sounds difficult, but in Lisp it isn't difficult at all. In Haskell this is a built-in feature and the way you implement it is just a no-brainer... * PaulPotts: Haskell is an even 'redder' pill than Lisp or Scheme * Pseudonym: Assuming an advanced compiler, your code will be sent to Oleg who will implement it in the type system. * cjeris: [wants ghc for wii] Build and deploy an army of functional dependencies and multi-parameter type classes to defend Hyrule from the menacing MUTATRON and his legion of Java programmers! * dons: My feeling is that the Java programmers will welcome us as liberators * greentea: To learn Monads, one must /become/ a Monad. * newsham: There are Just 1 types of people, Nothing and those who understand monads * vegai: In Soviet Russia, YOU blow up GHC's brain! Code Watch Wed Nov 29 11:24:21 PST 2006. simonpj. [65]Make SpecConstr work right for nullary constructors. For totally stupid reasons, SpecConstr didn't work for the (particularly easy) case of nullary constructors like True and False. I just had some equations in the wrong order, so that a Var case came first, which matches a nullary constructor, with the constructor-application case afterwards. The fix is easy. 65. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/18033 Fri Dec 1 04:53:04 PST 2006. Wolfgang Thaller. [66]Decouple -O from -fvia-C. Nowadays, there are situations where -fvia-C is definitely unwanted, such as when -fPIC is used on some platforms, so we do not want implicit -fvia-C any more. 66. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/18062 About the Haskell Weekly News Each week, new editions are posted to [67]the Haskell mailing list as well as to [68]the Haskell Sequence and [69]Planet Haskell. [70]RSS is also available, and headlines appear on [71]haskell.org. Headlines are available as PDF. The Haskell Weekly News is also [72]available in Spanish translation. To help create new editions of this newsletter, please see the [73]contributing information. Send stories to dons at cse.unsw.edu.au. The darcs repository is available at darcs get [74]http://www.cse.unsw.edu.au/~dons/code/hwn 67. http://www.haskell.org/mailman/listinfo/haskell 68. http://sequence.complete.org/ 69. http://planet.haskell.org/ 70. http://sequence.complete.org/node/feed 71. http://haskell.org/ 72. http://haskell.org/haskellwiki/HWN/es 73. http://haskell.org/haskellwiki/HWN 74. http://www.cse.unsw.edu.au/~dons/code/hwn

1 0

ANNOUNCE: Another Haskell MIME Library
by Dominic Steinitz 05 Dec '06

05 Dec '06

What's the betting they all have Base64 in them. Base64 is like a virus; everyone seems to have their own copy. I put it in the crypto library (along with MD5 another virus-like module) in the hope that we would end up with one version of both. Clearly that hasn't worked. Any suggestions? Dominic.

2 1

Help needed interrupting accepting a network connection
by Cat Dancer 04 Dec '06

04 Dec '06

I'd like to write a server accepting incoming network connections that can be gracefully shutdown. When the server is asked to shutdown, it should stop accepting new connections, finish processing any current connections, and then terminate. Clients can retry if they attempt to make a connection and the connection is refused. This allows the server to restart seamlessly: any existing connections are not interrupted, and clients will see at most a pause while the server restarts. I am using the model from Simon Marlow's Haskell Web Server (as updated by Björn Bringert and available at http://www.cs.chalmers.se/~bringert/darcs/hws/) spawning a lightweight Haskell child thread for each client connection. In Control.Exception, I see that operations such as "accept" are interruptible by exceptions thrown to the thread, so I can interrupt an accept with a dynamic exception. > -- create a datatype to use to interrupt the accept > data ExitGracefully = ExitGracefully deriving Typeable I want to control when I'm paying attention to the ExitGracefully exception. I don't want to get the exception when I'm in the middle of updating a data structure, just in a few controlled points such as when I'm in an accept. Reading further in Control.Exception, I see that I can use "block" to put off receiving the exception generally, but accept is an interruptible operation so I don't need to do anything more to get the exception inside of the accept. > block ( > ... > result <- catchDyn > (do (clientSocket, addr) <- accept sock > return $ Just clientSocket) > (\ (e :: ExitGracefully) -> return Nothing) Typing the exception "e" as an "ExitGracefully" tells catchDyn that I only need to catch exceptions of that type. If the thread has been thrown a ExitGracefully, "result" will be Nothing, but if accept returned with a client connection, "result" will be Just the clientSocket. > case result of > > Nothing -> do { putStrLn "accept loop exiting"; > putMVar acceptLoopDone () > } > > Just clientSocket -> So far so good. I also want to keep track of when the threads spawned to handle the client connections are finished, so I use the code from the "Terminating the program" section of the Control.Concurrent documentation to keep a list of MVar's indicating when the child threads are done: > childDone <- newEmptyMVar > childDoneList <- takeMVar childrenDone > putMVar childrenDone (childDone : childDoneList) then I fork a child thread to handle the connection: > clientHandle <- socketToHandle clientSocket ReadWriteMode > forkIO $ handleConnection childDone clientHandle "handleConnection" runs inside the child thread, communicating with the client. When done, it closes the clientHandle, and does an "putMVar childDone ()" to say that it done. Except that, whoops, the "takeMVar" in the accept thread code which updates the childrenDone" MVar is also interruptible. So now I'm getting an interruption right where I don't want it, when I'm updating my data structure. Only the accept thread is thrown the ExitGracefully exception, so one thought I had was that I could move those three lines which update the childrenDone MVar into the child thread. But this introduces a race condition: as the server was shutting down, it could look at the childrenDone list and see that it was empty, before the child thread had a chance to start running and update the data structure to say that there was another child that needed to be waited for. Or, updating the childrenDone MVar could be done in its own thread, which again would protect it from the ExitGracefully exception... except that how would the accept thread wait for that thread... except by using an MVar? Oops, again. Any ideas? For reference sake here's the complete implementation. (This code is in the public domain... in case it would be useful to anyone else). Thank you, Cat > -- A ConnectionHandler is a function which handles an incoming > -- client connection. The handler is run in its own thread, and is > -- passed a handle to the client socket. The handler does whatever > -- communication it wants to do with the client, and when it returns, > -- the client socket handle is closed and the thread terminates. > -- A list of active handlers is kept, and the client connection is > -- also marked as finished when the handler returns. > > type ConnectionHandler = Handle -> IO () > > > example_connection_handler :: ConnectionHandler > > example_connection_handler handle = do > hPutStrLn handle "Hello." > hPutStrLn handle "Goodbye." > > > type ChildrenDone = MVar [MVar ()] > > data ExitGracefully = ExitGracefully deriving Typeable > > > waitForChildren :: ChildrenDone -> IO () > > waitForChildren childrenDone = do > cs <- takeMVar childrenDone > case cs of > [] -> return () > m:ms -> do > putMVar childrenDone ms > takeMVar m > waitForChildren childrenDone > > > shutdownServer :: MVar () -> ChildrenDone -> ThreadId -> IO () > > shutdownServer acceptLoopDone childrenDone acceptThreadId = do > throwDynTo acceptThreadId ExitGracefully > takeMVar acceptLoopDone > waitForChildren childrenDone > return () > > > acceptConnections :: MVar () -> ChildrenDone -> ConnectionHandler -> Socket -> IO () > > acceptConnections acceptLoopDone childrenDone connectionHandler sock = do > block (acceptConnections' acceptLoopDone childrenDone connectionHandler sock) > > > acceptConnections' acceptLoopDone childrenDone connectionHandler sock = do > > result <- catchDyn > (do (clientSocket, addr) <- accept sock > return $ Just clientSocket) > (\ (e :: ExitGracefully) -> return Nothing) > > case result of > > Nothing -> do { putStrLn "accept loop exiting"; > putMVar acceptLoopDone () > } > > Just clientSocket -> > do clientHandle <- socketToHandle clientSocket ReadWriteMode > childDone <- newEmptyMVar > childDoneList <- takeMVar childrenDone > putMVar childrenDone (childDone : childDoneList) > forkIO $ handleConnection childDone connectionHandler clientHandle > acceptConnections' acceptLoopDone childrenDone connectionHandler sock > > > handleConnection childDone connectionHandler clientHandle = do > Exception.catch > (connectionHandler clientHandle > `finally` > do { hClose clientHandle; > putMVar childDone () }) > > -- TODO we'll want to do something better when > -- connectionHandler throws an exception, but > -- for now we'll at least display the exception. > (\e -> do { putStrLn $ show e; return () })

3 4

Jones-optimal, typed, symbolic differentiation of (compiled) functions
by oleg＠pobox.com 04 Dec '06

04 Dec '06

We show symbolic differentiation of a wide class of numeric functions without any interpretative overhead. The functions to symbolically differentiate can be given to us in a compiled form (in .hi files); their source code is not needed. We produce a (compiled, if needed) function that is an exact, algebraically simplified analytic derivative of the given function. Our approach is reifying code into its `dictionary view', intensional analysis of typed code expressions, and the use of staging to evaluate under lambda. This message is the improvement over the message posted on this list in November 2004. Rather than introduce our own expression data types, we use the one built in the Template Haskell (TH). TH lets us avoid the overhead of interpreting code expressions and achieve Jones-optimality. The computed derivative can be compiled down to the machine code and so it runs at full speed, as if it were written by hand to start with. In the process, we develop a simple type system for a subset of TH code expressions (TH is, sadly, completely untyped) -- so that accidental errors can be detected early. We introduce a few combinators for the intensional analysis of such typed code expressions. We also show how to reify an identifier like (+) to a TH.Name to match on -- by applying TH to itself. Effectively we obtain more than one stage of computation. Conversion from a TH code expression to code is a common operation built into TH: splicing. The spliced code becomes the part of the host program and can be compiled along with it. The reverse transformation, from the compiled code to the TH code expression, is quite less common. Once we recover the source code view of a (compiled) function, we can convert it back to the compiled code with TH splicing. We can also simplify the code, eliminate common subexpressions by let insertions, partially evaluate the code -- or, the subject of this message, differentiate the code and apply a few algebraic simplifications. It should be stressed that we take a function of the type Floating a => a -> a and return another (derived) function of that type. The straightforward approach would be to transform \x -> body into \x -> derive body We see the obvious drawback: we have to evaluate 'derive body' every time we apply the derivative function. Our approach is different: to put it a bit informally, we compute let body' = derive body in \x -> body' That approach requires evaluating under lambda, which is the main benefit of staging. We should make another point: symbolic differentiation presupposes that the function is represented by a data type such as data Exp = Var | Add Exp Exp ... Therefore, the result of symbolic differentiation would be \x -> interpret (derive body) where 'interpret' is a function of the type 'Exp -> Float'. That approach results in the overhead of interpreting Exp on each invocation of the function. Staging again lets us eliminate such an overhead. We really operate on the code, in the same form that compiler sees it. Let us take a simple example. Given the function > test1f x = let y = x * x in y + 1 (which can be in a separately compiled file), we can reify it into a TH code expression and print it: > test1c = new'diffVar >>= \ (v::Var Float) -> return $ (test1f (var'exp v),v) > test1r = test1c >>= \ (c,v) -> reflectDF v c > test1cp = showQC test1r *Diff> test1cp \dx_0 -> GHC.Num.+ (GHC.Num.* dx_0 dx_0) 1 The output is produced by TH's pretty-printer -- which, I suspect, is the same function used by GHC to print expressions in error messages. Predictably, the let expression in the original function is `inlined'; what we obtain is a `dictionary' view of the function. We can splice the obtained code back into program; we can also differentiate it symbolically: > test1d = test1c >>= \ (c,v) -> reflectDF v $ diffC v c > test1dp = showQC test1d *Diff> test1dp \dx_0 -> GHC.Num.+ (GHC.Num.+ (GHC.Num.* 1 dx_0) (GHC.Num.* dx_0 1)) 0 That is not too nice, so we do a bit of algebraic simplifications > test1ds = test1c >>= \ (c,v) -> reflectDF v $ simpleC v $ diffC v c > test1dsp = showQC test1ds *Diff> test1dsp \dx_0 -> GHC.Num.+ dx_0 dx_0 which is quite better. We can splice that code in a Haskell program, and apply the result as a regular Haskell function: > test1ds' = $(reflectQC test1ds) 2.0 The full code is available from the directory: http://pobox.com/~oleg/ftp/Haskell/differentiation/ The file differentiation.lhs in that directory is the old message, posted on the Haskell mailing list in November 2004. The other files are new. Sorry about too many files: TH demands splitting the code across modules. If you're using GHC 6.6, please edit the file TypedCodeAux.hs and comment one definition and uncomment the other one, as described in the code. In GHC 6.6, TH API has changed a bit. The file TypedCode.hs introduces the type "Code a" of typed TH code expressions. The (phantom) type parameter is the expression's type. The file also defines combinators for building and analyzing these typed expressions. The main file is Diff.hs. It gives the reification of code into TH code, differentiation rules and algebraic simplification rules, all via the intentional analysis of the typed code. The differentiation function is as follows: > diff_fn :: Floating b => (forall a. Floating a => a -> a) -> QCode (b -> b) > diff_fn f = > do > v <- new'diffVar > let body = f (var'exp v) -- reified body of the function > reflectDF v . simpleC v . diffC v $ body -- differentiate and simplify which closely follows the informal outline described above. Here's a more involved example, > test2f x = foldl (\z c -> x*z + c) 0 [1,2,3] > test2n = test2f (4::Float) -- 27.0 > test2s = show_fn test2f If we just reflect this function (so we can print its code, test2s), we obtain *Diff> test2s \dx_0 -> GHC.Num.+ (GHC.Num.* dx_0 (GHC.Num.+ (GHC.Num.* dx_0 (GHC.Num.+ (GHC.Num.* dx_0 0) 1)) 2)) 3 Its differentiation gives us > test2ds = showQC (diff_fn test2f) *Diff> test2ds \dx_0 -> GHC.Num.+ (GHC.Num.+ dx_0 2) dx_0 which is not too bad. Again, the result can be spliced in and used as a regular Haskell function. The result obviously has no interpretative overhead. > test2dn = $(reflectQC (diff_fn test2f)) (4::Float) > -- 10.0 The file Diff.hs has more complex examples, such as differentiating > test5f x = sin (5*x + pi/2) + cos(1 / x) The file also demonstrates partial derivatives. To finish this message, we show a sample of differentiation rules > diffC :: (Floating a, Floating b) => Var b -> Code a -> Code a > -- differentiating x/y > diffC v c | Just (x,y) <- on'2opC op'div c = > ((diffC v x) * y - x * (diffC v y)) / (y*y) > ... The intensional analysis of the code should be obvious. Here's a sample simplification rule > simpleCL :: Floating a => Var b -> Code a -> Maybe (Code a) > simpleCL v c | Just (x,y) <- on'2opC op'add c = > simple'recur op'add sadd v x y > where > sadd x y | Just 0 <- on'litRationalC x = Just y > sadd x y | Just 0 <- on'litRationalC y = Just x > -- constant folding > sadd x y | (Just x, Just y) <- (on'litRationalC x, on'litRationalC y) > = Just (fromRational $ x + y) > sadd x y = Nothing The function simpleCL is repeatedly applied to a code expression until it reports that no simplifications have been made.

1 0

Re: [Haskell] Help needed interrupting accepting a network connection
by Chris Kuklewicz 03 Dec '06

03 Dec '06

Cat Dancer wrote: >> > I'd certainly be most happy not to use asynchronous exceptions as the >> > signalling mechanism, but how would you break out of the accept, >> > except by receiving an asynchronous exception? >> >> Short Version: You trigger a graceful exit using a TVar... >> ...and then you use killThread to break out of accept. > > Oh, OK, you're still using an asynchronous exception to break out of > the accept (killThread throws a ThreadKilled asynchronous exception to > the thread), but you're using STM to *signal* the graceful exit > instead of using the asynchronous exception as the signalling > mechanism. Nice. > > Thanks. My ghc 6.6 (needed for newTVarIO) installation is broken for > some reason, so I'll need to fix that tomorrow and then I'll be able > to try your code. Since newTVarIO is not in unsafePerformIO, you can replace it with "atomically (newTVar)" > >> (mv,tid) <- fork (forever (accept socket >>= syncTMVar chan)) > > It looks like to me you could get a connection from "accept" but then > get a ThreadKilled exception before the "syncTMVar chan" executes, and > then the connection would be left open and hanging until it was > eventually garbage collected? Sigh. I missed that one. Not bad to fix, just use block and split syncTMVar, putting the unblocked empty check before the accept. I also switched to using "cond", a kind of flipped "if". The new code: cond true false test = if test then true else false acceptUntil socket receiver childrenList checker = do chan <- newEmptyTMVarIO (mv,tid) <- fork . block . forever $ do unblock . atomically $ isEmptyTMVar chan >>= cond (return ()) retry client <- accept socket atomically (putTMVar chan client) let loop = do result <- atomically (fmap Left checker `orElse` fmap Right (takeTMVar chan)) case result of Left _ -> return () Right client -> spawn client >> loop spawn client@(handle,_,_) = do cInfo <- fork (finally (receiver client) (hClose handle)) modifyMVar_ childrenList (return . (cInfo:)) end = do killThread tid readMVar mv maybeClient <- atomically (tryTakeTMVar chan) maybe (return ()) spawn maybeClient finally (handle (\e -> throwTo tid e >> throw e) loop) end The new code makes sure chan is empty, and so we are sure the putTMVar chan will never have to wait so it will never unblock (I just wrote and ran short test to confirm this). I think this is fixed now.

1 2

Using putStrLn/printf from DLL in GUI application
by Krasimir Angelov 03 Dec '06

03 Dec '06

How many times you tried to use putStrLn from Haskell or printf from C when you are building DLL loaded in GUI application? This simply doesn't work because by default the GUI application doesn't have console window. The solution is to use allocConsole/freeConsole from the attached library. Example: do allocConsole ..... ..... putStrLn "Hello, world!" ..... ..... freeConsole This could be a good addition to the standard Win32 library if someone take care to integrate it. Cheers, Krasimir

2 3

ANNOUNCE: Another Haskell MIME Library
by Jeremy Shaw 03 Dec '06

03 Dec '06

Hello, I would like to announce the availability of my partially complete MIME processing library. This library is supposed to be able to parse emails and decode various attachments, and generate emails with attachments. The library includes modules that implement portions of: RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types RFC 2387 - The MIME Multipart/Related Content-type RFC 2822 - Internet Message Format This library is intended to parse real emails -- so it is not a strict as the specifications. TODO: There is enough code in place to read in a multipart email with attachments and decode the parts into an output directory. I believe there is less support for encoding messages. So, in terms of basic functionality, there is still a fair bit left to do. The library namespace is probably wrong, instead MIME.* I should probably move it to Text.MIME.* or something. More significantly, the library was written prior to ByteString -- it would make a lot of sense to update it to support lazy byte strings, since MIME messages are often rather large. In any case, I wanted to release this library now since I know other people are already duplicating some (all?) of the work :) I am quite happy to accept patches. If someone else has a better code base already, I am happy to jump ship and work on that code instead. Either way, I am trying to get a usuable MIME library by the end of the month. AVAILABILITY: darcs get http://www.n-heptane.com/nhlab/repos/haskell-mime There is also a short blurb about it on the bottom of this page: http://www.n-heptane.com/nhlab/ j.

3 3