December 2006 - Haskell

ANN: AnyDBM 1.0.0
by John Goerzen 08 Dec '06

08 Dec '06

AnyDBM 1.0.0 has been released today. AnyDBM is a generic DBM-type interface. It provides a generic infrastructure for supporting storage of hash-like items with String-to-String mappings. It can be used for in-memory or on-disk storage. Two simple backend drivers are included with this package: one that is RAM-only, and one that is persistent and disk-backed. The hdbc-anydbm package provides another driver, which lets you use simple tables in any SQL database to provide a DBM-like interface. MissingPy also provides a Python driver which lets you use any Python anydbm driver under Haskell AnyDBM. AnyDBM was previously a part of the MissingH library. The code in this release is unchanged from its state in MissingH, other than the changes necessary to make it a standalone package. You can find the AnyDBM homepage, which features a wiki, downloads, API reference, darcs repository viewer, and bug tracker, at: http://software.complete.org/anydbm

1 0

ANN: ftphs
by John Goerzen 08 Dec '06

08 Dec '06

I'm pleased to announce the first standalone release of ftphs. ftphs is an FTP client and server library for Haskell. Its features include: * Easy to use operation * Full support of text and binary transfers * Optional lazy interaction * Server can serve up a real or a virtual filesystem tree * Standards compliant ftphs was previously a part of the MissingH library. The code in this release is unchanged from its state in MissingH, other than the changes necessary to make it a standalone package. You can find the ftphs homepage, which features a wiki, downloads, API reference, darcs repository viewer, and bug tracker, at: http://software.complete.org/ftphs

1 0

Network accept loop with graceful shutdown implementation
by Cat Dancer 08 Dec '06

08 Dec '06

I have a prospective implementation of a network accept loop with graceful shutdown. This email builds upon the previous discussion "Help needed interrupting accepting a network connection". In this code, just the accept loop part has been factored out and put into its own module. My hope is that if a fully correct version can be written, it will be useful to other projects. The source is available at http://code.catdancer.ws/acceptloop/ and is in the public domain. This AcceptLoop module is currently experimental, relying on an "either-or" guarantee for interruptible operations... which I don't know yet whether Haskell implementations provide -- or even intend to provide. Chris Kuklewicz provided several critical insights: * The return value of the 'accept' call can be passed out of the accept thread, allowing the code which implements accept with graceful shutdown to be separated from the code which handles the incoming client connection. * Inside of a 'block', interruptible operations may not (will not?) allow an asynchronous exception to be raised if the operation does not block. * Clarification for me of the desirable property that inside of a 'block', interruptible operations are either-or: either they allow an asynchronous operation to be raised, or they perform their operation, but not both. I made the following design decisions: In my original implementation, I used a custom datatype to throw a dynamic asynchronous exception to the thread calling 'accept'. In Chris' rewrite, he used 'killThread', which throws a 'ThreadKilled' asynchronous exception. I choose to continue to throw (and catch) only the specific, custom exception for the purpose of breaking out of the 'accept'. A robust implementation may need to catch other exceptions, however the desired behavior of the thread on receiving an *unexpected* exception may be different, and so I choose to leave handling of such an unexpected exception unimplemented for now. Chris uses STM instead of MVar's for communication with the accept thread. The challenge of writing code with STM or MVar's in the presence of asynchronous exceptions is exactly the same: either a call to 'atomically' or a call to an MVar operation such as 'putMVar' may allow an asynchronous exception to be raised inside of a 'block', and the code then needs to deal with that. It seems to me that MVar's could be implemented in terms of STM, and so the question is: are MVar's a more natural, higher level description of the desired semantics in this case, and would composable transactions be useful? A key insight is that in this implementation, a separate thread is used not for the purposes of concurrency, but solely to limit the scope of the thrown asynchronous exception. Once a result is available from the accept thread (either "Just" an incoming connection, or "Nothing" to say that the accept loop has shutdown), that result can then be used in a concurrent fashion, such as being handled in a child thread, passed into an STM transaction or written to a channel, etc. But there is no need to use composable transactions *inside* of the AcceptLoop module. Thus the only reason to use STM instead of MVar's inside the implementation is if it turns out that STM has the desired "either-or" behavior but MVar's don't. To avoid the "unlock (return ())" issue that Chris discovered, this implementation uses an additional MVar to indicate that a shutdown is in process. Thus (if the implementation is correct) the accept loop will shutdown either because of the MVar flag or by receiving the asynchronous exception inside of the 'accept'. To address the issue that Chris noticed of a race condition that new threads cannot be started in a 'block' state, yet another MVar is set by the accept thread to indicate that it is now inside of a 'block' and is ready to receive the asynchronous exception.

4 4

Re: GHC Error question
by oleg＠pobox.com 08 Dec '06

08 Dec '06

Norman Ramsey wrote: > compile1 :: (Builder b box) => t -> Name -> Ir.ANF -> b t > compile1 f x body = do env <- compile body empty > wire (Arg W) (env x) > return f > class (Monad b) => Builder b box where > wire :: Source box -> Sink box -> b () > This program is rejected by GHC with the following message: > > Ccomp.hs:54:23: > Could not deduce (Builder b box1) from the context (Builder b box) > arising from use of `wire' at Ccomp.hs:54:23-42 He continued, [paraphrase] however, compile1 is accepted if the signature is removed. Furthermore, the inferred signature seems identical to the one given above. That is not a bug. We observe that in the explicitly given signature of compile1 > compile1 :: (Builder b box) => t -> Name -> Ir.ANF -> b t the type variable 'box' occurs only in the constraint Builder. The use of `wire' in the body of compile1 entails the constraint `Builder b1 box1' (we alpha-renamed the type variables). Now, we know that the result of the wire is the monadic value 'b1 ()', and compile1, according to the signature, produces the monadic value 'b t. So, the typechecker concludes that b = b1. However, there is nothing in the code that lets the typechecker conclude that box1 is the same as box. Hence the error: the given constraint (Builder b box) differs from the required (Builder b box1). What to do? If applicable, add a functional dependency (either per class or per instance) so to tell the typechecker that a particular 'b' (always, or in some cases) entails the particular 'box'. That will provide the missing improvement equation `box = box1'. Or, one may use the local type variable to the same end > compile1 :: forall b t box. (Builder b box) => t -> Name -> Ir.ANF -> b t > compile1 f x body = do env <- compile body empty > wire ((Arg W)::Source box) (env x) > return f the explicit `forall' binder is required.

3 5

haddock-via-cabal: --prologue option?
by Conal Elliott 08 Dec '06

08 Dec '06

Is it possible to get haddock's --prologue flag passed in through cabal? Is there perhaps a way to get arbitrary options passed in? - Conal

2 2

Higher kind type inference paper
by Edsko de Vries 07 Dec '06

07 Dec '06

Hi, Are there any papers that describe how higher kind type inference (and I really mean higher kind, not higher rank) is done? Thanks, Edsko

3 2

ANN: hslogger
by John Goerzen 06 Dec '06

06 Dec '06

Hi, I'm pleased to announce the release of hslogger, a logging framework for Haskell. hslogger's features include: * Each log message has a priority and a source associated with it * Multiple log writers can be on the system * Configurable global actions based on priority and source * Extensible log writers (handlers) * Default handlers that write to the console, file handles, or * syslog * Easy to use operation You can find hslogger online at: http://software.complete.org/hslogger hslogger is the first package to be split off from the MissingH source tree. -- John

1 0

cabal + haddock on Windows default paths working?
by Conal Elliott 06 Dec '06

06 Dec '06

When I configure libraries (monadLib, arrows) with default locations and then cabal-haddock my own library, I get this sort of warning: Warning: cannot use package arrows-0.2: HTML directory "C:\\Program Files\\Common Files\\arrows-0.2\\doc\\html" does not exist. That directory *does* exist, however, and contains the arrow library's haddock-generated files. Any ideas? Is any Windows haddock user *not* having this problem? Am I running into a bug in handling of path names with embedded spaces? Thanks, - Conal

2 1

haddock not finding base lib docs -- $topdir ?
by Conal Elliott 05 Dec '06

05 Dec '06

I'm running haddock for the first time, via cabal. I get the following message when i do "runhaskell Setup.hs haddock" on monadLib: Warning: cannot use package base-2.0: HTML directory $topdir\html\libraries\base does not exist. I do have c:/ghc/ghc-6.6/doc/html/libraries/base/. Is there some way i can let cabal know how to find it? What is $topdir about? Thanks, - Conal

3 5

GHC Error question
by nr＠eecs.harvard.edu 05 Dec '06

05 Dec '06

Without going too deep into the details of my type classes, I have written the following code (focusing on compile1): {-# OPTIONS -fglasgow-exts #-} compile1 :: (Builder b box) => t -> Name -> Ir.ANF -> b t compile1 f x body = do env <- compile body empty wire (Arg W) (env x) return f compile :: (Builder b box) => Ir.ANF -> Env box -> b (Env box) class (Monad b) => Builder b box where wire :: Source box -> Sink box -> b () ... type Env box = Name -> Sink box This program is rejected by GHC with the following message: Ccomp.hs:54:23: Could not deduce (Builder b box1) from the context (Builder b box) arising from use of `wire' at Ccomp.hs:54:23-42 Possible fix: add (Builder b box1) to the type signature(s) for `compile1' In the expression: wire (Arg W) (env x) In a 'do' expression: wire (Arg W) (env x) In the expression: do env <- compile body empty wire (Arg W) (env x) return f Note that compile1 has an explicit type signature much along the lines suggested by GHC. If I *remove* this type signature, the function compiles successfully, and ghci reporets this type for compile1: compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 I believe this signature is isomorphic to the explicit signature I had attempted to use. Am I misusing the type-class system in some way, or should I be reporting a bug in GHC? Norman

1 0