- Haskell - Haskell.org

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 03 Dec '06

03 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 02 Dec '06

02 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

ESSLLI 2007 Student Session - Second Call for Papers
by Ville Nurmi 01 Dec '06

01 Dec '06

[Our apologies for multiple postings of this announcement.] ESSLLI 2007 STUDENT SESSION CALL FOR PAPERS August 6-17 2007, Dublin, Ireland Deadline: February 11, 2007 http://www.loria.fr/~sustreto/stus07/ We are pleased to announce the Student Session of the 19th European Summer School in Logic, Language and Information, which will be held in Dublin, Ireland on August 6-17, 2007. We invite submission of papers in the areas of Logic, Language and Computation for presentation at the Student Session and for appearance in the proceedings. AIM Student Session exists to bring together young researchers to present and discuss their work in progress with a possibility to get feedback from senior researchers. SUBMISSION Only original publications are accepted, previous published works are not allowed. All authors of the paper must be students: undergraduate (before the completion of the Masters degree) or graduate (before the completion of the PhD degree). Papers can be submitted either for oral (20min talk+10 min discussion), or poster presentation. There are three subject areas: Logic and Language (lola), Language and Computation (laco) and Logic and Computation (loco). The submissions should be sent by email before 11 February 2007 to dmitry.sustretov(a)loria.fr (the message should have subject "ESSLLI STUS submission") along with an identification file in plain text of the following format: Title: title of the submission First author: firstname lastname Affiliation: affiliation of the first author E-mail: e-mail of the first author ...... Last author: firstname lastname Affiliation: affiliation of the last author E-mail: e-mail of the last author Abstract: (5 lines) Subject area: Logic and Language or Language and Computation or Logic and Computation Modality: Poster or Oral The submission should be in one of the following formats: PostScript, PDF or RTF. (In case of acceptance, the final version of the paper will have to be submitted in LaTeX format.) The papers must use single column A4 size pages, 11pt or 12pt fonts, and standard margins, and may not exceed 7 pages of length exclusive of references. The paper and identification file should be named by the following convention: category-modality-last name(s) of author(s) (for example, "loco-oral-martin.pdf" and "loco-oral-martin.txt"). At least one of the authors of the paper must register as a participant of ESSLLI. Accepted papers will be published in the proceedings which will be available during ESSLLI. TIMELINE Submission deadline: February 11, 2007 Notification of authors: April 20, 2007 Full paper deadline: May 20, 2007 ESSLLI: August 6-17, 2007 PROGRAM COMMITTEE Chairs: Ville Nurmi and Dmitry Sustretov Co-chairs: Logic and Computation Bryan Renne, City University of New York Levan Uridia, University of Amsterdam Language & Computation Luciana Benotti, INRIA Lorraine Michael Kaisser, University of Edinburgh Logic & Language Jana Häussler, University of Konstanz Miltiadis Kokkonidis, University of Oxford CONTACT The Student Session webpage is the place for relevant information. http://www.loria.fr/~sustreto/stus07/ Feel free to contact the chairs for any questions about the submissions or the Student Session in general. Ville Nurmi Phone: +358 9 191 51497 Fax: +358 9 191 51400 E-mail: ville.v.nurmi(a)helsinki.fi Dmitry Sustretov Phone: +33 3 83 59 20 35 Fax: +33 3 83 41 30 79 E-mail: dmitry.sustretov(a)loria.fr

1 0

First Call for Papers: TFP 2007, New York
by Marco Morazan 01 Dec '06

01 Dec '06

CALL FOR PAPERS Trends in Functional Programming 2007 New York, USA April 2-4, 2007 http://cs.shu.edu/tfp2007/ <http://tltc.shu.edu/tfp2007/> OR *http://tltc.shu.edu/tfp2007/* ** ** The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2007 is co-hosted by Seton Hall University and The City College of New York (CCNY) and will be held in New York, USA, April 2-4, 2007 at the CCNY campus. SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles leading-edge, previously unpublished research work Position Articles on what new trends should or should not be Project Articles descriptions of recently started new projects Evaluation Articles what lessons can be drawn from a finished project Overview Articles summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Articles on the following subject areas are particularly welcomed: o Dependently Typed Functional Programming o Validation and Verification of Functional Programs o Debugging for Functional Languages o Functional Programming and Security o Functional Programming and Mobility o Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications o Functional Languages for Telecommunications Applications o Functional Languages for Embedded Systems o Functional Programming Applied to Global Computing o Functional GRIDs o Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) o Interoperability with Imperative Programming Languages o Novel Memory Management Techniques o Parallel/Concurrent Functional Languages o Program Transformation Techniques o Empirical Performance Studies o Abstract/Virtual Machines and Compilers for Functional Languages o New Implementation Strategies o any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2007 program chair, Marco T. Morazan, at tfp2007(a)shu.edu. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of extended abstracts (6 to 10 pages in length) by the program committee. Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings and on-line. Further details can be found at the TFP 2007 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. IMPORTANT DATES Abstract Submission: February 1, 2007 Notification of Acceptance: February 20, 2007 Registration Deadline: March 2, 2007 Camera Ready Full Paper Due: March 9, 2007 TFP Symposium: April 2-4, 2007 PROGRAMME COMMITTEE John Clements California Polytechnic State University, USA Marko van Eekelen Radboud Universiteit Nijmegen, The Netherlands Benjamin Goldberg New York University, USA Kevin Hammond University of St. Andrews, UK Patricia Johann Rutgers University, USA Hans-Wolfgang Loidl Ludwig-Maximilians Universität München, Germany Rita Loogen Philipps-Universität Marburg, Germany Greg Michaelson Heriot-Watt University, UK Marco T. Morazán (Chair) Seton Hall University, USA Henrik Nilsson University of Nottingham, UK Chris Okasaki United States Military Academy at West Point, USA Rex Page University of Oklahoma, USA Ricardo Pena Universidad Complutense de Madrid, Spain Benjamin C. Pierce University of Pennsylvania, USA John Reppy University of Chicago, USA Ulrik P. Schultz University of Southern Denmark, Denmark Clara Segura Universidad Complutense de Madrid, Spain Jocelyn Sérot Université Blaise Pascal, France Zhong Shao Yale University, USA Olin Shivers Georgia Institute of Technology, USA Phil Trinder Heriot-Watt University, UK David Walker Princeton University, USA ORGANIZATION Symposium Chair: Henrik Nilsson, University of Nottingham, UK Programme Chair: Marco T. Morazan, Seton Hall University, USA Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Marco T. Morazan, Seton Hall University, USA

1 0

Announce of Core (ghc-base) library
by Bulat Ziganshin 01 Dec '06

01 Dec '06

This message is of primary interest for developers of Haskell compilers and core libraries. it duplicated at http://haskell.org/haskellwiki/Library/Core Thanks to Cabal, now we can easily upgrade any installed library to new version. There is only one exception - Base library that is closely tied to compiler internals, so you cannot use Base library shipped with GHC 6.4 in GHC 6.6 and vice versa. The Core library is a project of dividing 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. Then, any version of Base library can be used with any version of Core library, i.e. with any compiler. Moreover, it means that Base library will become available for the new compilers, like yhc and jhc - this will required adding to Core lib only a small amount of code implementing low-level compiler-specific functionality. Core library consists of directories GhcCore, HugsCore... implementing compiler-specific functionality and Core directory providing common interface to this functionality, so that external libs should import only Core.* modules in order to be compiler-independent. In practice, implementation of Core lib became a refactoring of GHC.* modules by splitting them into GHC-specific and compiler-independent parts. Adding then implementations of compiler-specific parts for other compilers will allow us to compile refactored Base library by any compiler including old versions of GHC. At this moment, the following modules was succesfully refactored: GHC.Arr, GHC.Base, GHC.Enum, GHC.Float, GHC.List, GHC.Num, GHC.Real, GHC.Show, GHC.ST, GHC.STRef, and the next step is to refactor IO functionality Like the original GHC.* modules, Core library builds up its functionality in layers, where each next layer use features provided by previous ones. Already written layers are, in order of dependencies: Base Integer Integral Float ST/Int/Word Arr Each layer includes both compiler-specific and compiler-independent modules, say first layer is represented by GhcCore.Base/HugsCore.Base and Core.Base modules in contrast to initial design i proposed, compiler-dependent modules in each layer can import and use compiler-independent functionality of previous layers, this greatly simplifies writing of compiler-dependent code and allow to avoid code duplication. For example, GhcCore.* modules widely use && operation defined in Core.Base module. So, when compiling with GHC, dependencies order will be as follows: GhcCore.Base -> Core.Base -> GhcCore.Integer -> Core.Integer -> ... at last end, this mean that Core library can't be split to GhcCore, HugsCore and other separate ones, but need to be united library that includes code for all compilers we support speaking in terms of versions, Base and other higher-level libraries can request specific Core version (say, 2.0.*) and be sure that some set of services should be available. Inside these version range, Core library may grow to support additional compiler versions, say only GHC 6.6 in 2.0.0, GHC 6.6/6.8 and Hugs 2006 in 2.0.1 and so on Why i stopped further development of Core at this stage? First, it was not so hard task - in a week or two i've refactored, afair, 1/3 of GHC.* code. My next goal was to implement Hugs support for all already implemented facilities, but i find serious problems with redefinition of Prelude types and classes. may be, using a feature of upgrading Base, this will become no problem. The same problem, although in less degree, i had with GHC too Second problem that stopped me was I/O part of GHC.* library. It seems impossible to move this out of Core (!) library because Handle type used in definition of Exception type which used by 'fail' for IO Monad and IO monad used everywhere. so, we need some brainstorming to analyze the situation and general tendency of Base library to use too many dependencies. One example was provided by Ross: Data.HashTable is used in Data.Dynamic, that is used in Exception.. so, again, it can't be moved out of Core lib! but even if we can't extract Core library from Base as "compliler-equalizer" subset of modules which includes only Core.* and don't includes Data.*, System.* and other code, at least it's possible to split existing GHC.* code into simple compiler-dependent and more complex compiler-independent parts and simplify way to support 1) new compilers like JHC and YHC 2) range of compiler versions instead of just one version so, i hope that this work will be interesting and helpful for community, especially in order to help new compilers support rich set of libraries with a minimal effort library is available as http://www.haskell.org/library/Core.tar.gz please note that Data.* modules should be considered not as part of library but as examples of modules from future Base library that will be based on services provided by Core -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

ANNOUNCE: Haskell Communities & Activities Report (11th ed., November 2006)
by Andres Loeh 30 Nov '06

30 Nov '06

On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (11th edition, November 2006) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: PDF, for screenreading as well as printing, HTML, for those of you who prefer not to deal with plugins or external viewers, and PostScript, for those of you who have nice quick printers that do not grok PDF. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as we did. If you haven't encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the actual deadline ;) ) to the call. The editor collects all the contributions into a single report and feeds that back to the community. 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. So, please put the following into your diaries now: ---------------------------------------- End of April 2007: target deadline for contributions to the May 2006 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to `register' with the editor for a simple e-mail reminder in the middle of April (you could point me to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Andres Loeh <hcar at haskell.org> -- Haskell Communities and Activities Report (http://haskell.org/communities)

1 0

ANNOUNCE: Visual Haskell prerelease 0.2
by Krasimir Angelov 30 Nov '06

30 Nov '06

Hello Haskellers, I am happy to announce that there is a prerelease version of Visual Haskell on: http://www.haskell.org/visualhaskell This is the first version that is: - available for both VStudio 2003 and VStudio 2005 - distributed with a stable GHC version (6.6) This is still prerelease version but if there aren't any bug reports in the next few days I will just rename it to release. Many thanks to Simon Marlow, Brian Smith, Wayne Vucenic, Jared Updike and Pepe Iborra that helped me with the preparation of this new release. Cheers, Krasimir

6 11