- Libraries - Haskell.org

Fixing MonadIO
by Yitzchak Gale 05 Feb '08

05 Feb '08

Simon Marlow wrote: > Avoiding > exceptions because MonadIO has trouble with them is not a good enough > reason, IMO. We should fix MonadIO instead. I'm all for it! Below is a summary of the three approaches that have been proposed, as far as I can remember: 1. Make the functions in Control.Exception more polymorphic. This is part of the more general program of providing polymorphic IO described in Haskell' ticket 110. Brian Hulley attached to that ticket a version of Control.Exception that does this by introducing the MonadException subclass of MonadIO. http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Excepti… 2. In another branch from this thread, I suggested adding only the following three low-level exception handling functions to Control.Exception: startDelayingExceptions stopDelayingExceptions getDelayedException This would allow exception handling to be extended arbitrarily in other libraries, with only a small addition to Control.Exception. Simon Marlow pointed out that this mechanism would lose certain optimizations that exist, e.g., for preserving tail-recursion in block. That would be a cost of this generality. (Obviously we would retain the current mechanism for IO itself.) http://www.haskell.org/pipermail/libraries/2008-February/009159.html 3. Earlier in this thread, Judah Jacobson proposed adding additional liftIO functions to MonadIO, or a subclass, that match the kinds of the exception handling functions of Control.Exception. The kinds that would be needed are: For block and unblock: * -> * For catch: * -> (* -> *) -> * For setUncaughtExceptionHandler: (* -> *) -> * The liftIO for catch is the most general, so it could be reused for the others, but that would look a little ad hoc. This approach has the advantage that it does not require any change at all to Control.Exception, but it puts more of a burden on monad authors. http://www.haskell.org/pipermail/libraries/2008-January/009034.html Any other approaches? Any opinions about which of these would be best? Thanks, Yitz

3 3

darcs patch: Figure out timezone offset from timezone name
by David Leuschner 05 Feb '08

05 Feb '08

Sat Feb 2 12:33:17 CET 2008 David Leuschner <david(a)loisch.de> * Figure out timezone offset from timezone name

7 12

MonadIO and IO exceptions
by Yitzchak Gale 03 Feb '08

03 Feb '08

Judah Jacobson wrote: > I've already demonstrated how a library writer can solve that problem in: > http://www.haskell.org/pipermail/libraries/2008-January/009034.html Yes, that is indeed very nice. But I don't think it is a practical solution right now, for the following reasons: It requires that users be in a special monad; it doesn't work for regular MonadIO. So it isn't really a practical solution until it gets into MTL and people start porting their code. Providing an instance for MonadIO1 (or whatever we would call it) is an extra step for monad writers that may often be skipped. Also, there are obviously many other more complex cases beyond a simple bracket. How general is this technique? As you point out, even for bracket it does not work unless the "after" action is IO. What other restrictions are there in the general case? Perhaps we could fix those problems by also providing liftIOk for all kinds k that occur in the signatures of various functions in Control.Exception. But that would make the new monad even more unwieldy. As I suggested before, I think the best solution would be to define the functions of Control.Exception in terms of lower-level primitives that could then be used to define the functions directly for other monads. Perhaps something like this would be general enough to cover everything: -- Delay any exception and put in buffer startDelayingExceptions :: IO () -- Stop delaying exceptions stopDelayingExceptions :: IO () -- Retrieve delayed exception and clear buffer getDelayedException :: IO (Maybe Exception) There would be one exception buffer per thread. New exceptions would replace old ones, so users of this mechanism would be required to catch as catch can. Based on Simon Marlow's observation in our previous discussion on this topic, we would still want to leave around the current primitives as a special case optimization for IO. Regards, Yitz

1 0

Fwd: Readline read_history and write_history addition
by Alexander Dunlap 03 Feb '08

03 Feb '08

On Feb 2, 2008 1:14 PM, Yitzchak Gale <gale(a)sefer.org> wrote: > Alexander Dunlap wrote: > >>> For instances where an exception would be too intrusive, I don't see > >>> how it would be too hard to write a wrapper function > > I wrote: > >> In a library that does not have direct access to the IO > >> monad, it would be not just hard - it would be impossible. > >> That is because of type restrictions in the current versions > >> of catch, block, and friends. > > Judah Jacobson wrote: > > You haven't said why something like the following would not be sufficient: > > > > readHistoryM :: MonadIO m => String -> m Bool > > readHistoryM file = liftIO $ do > > result <- try (readHistory file) > > return (result == Right ()) > > Because a library - other than readline itself - can't > force its users to do that. > > OK. Here's a simplified real-world example. Say you want to > write a simple library that interfaces the text-to-speech facilities > available on multiple platforms. To play nicely with programs > written in a monadic style, the interface might be something like: > > class MonadIO m => Speech m where > sayText :: String -> m () > runSpeech :: m a -> IO a > > instance Speech SomeSpeechSystem where > sayText t = ... > runSpeech x = do > liftIO startSomeSpeechSystem > ret <- x > liftIO stopSomeSpeechSystem > return ret > > Unfortunately, bracket is not available. So if x throws an > uncaught IO exception, you may leave around zombies, > database corruption, missiles armed for launch, etc. > > Well, if your speech system doesn't arm any missiles, > you may consider it a reasonable risk to use this > library in programs that could throw an IO exception > on some rare error condition. > > But the proposal here is to raise the exception in a > common situation that will definitely occur in regular > usage. That may be fine in Java or Python, but it > is a bad idea for IO exceptions in Haskell. > > Alexander Dunlap wrote: > > So why couldn't you have a Utils.hs file that imports System.IO and > > provides the wrapper around readHistory? Then you can use the > > tryReadHistory function in your MonadIO-exporting module _exactly_ the > > same way as the original readHistory function. > > You can. But if you are writing a library, your users > might not. > > Regards, > Yitz > I don't understand. Why don't you compile the functions we are suggesting _into the library_? Alex

2 1

Proposal: Add variants of tails & inits not returning empty lists
by Maxime Henrion 01 Feb '08

01 Feb '08

Hi all, I just opened a Trac ticket (#1979), to suggest the addition of the inits1 and tails1 functions, which don't return empty lists unlike their counterpart. They're defined as such : inits1 = tail . inits tails1 = init . tails I've needed them a few times so I thought they would make a nice addition to the base package. And, I've got to say, the symmetry in this code is is nice :-). http://hackage.haskell.org/trac/ghc/ticket/1979 Cheers, Maxime

7 10

Security Notice: Buffer overflow fixed in PCRE library
by ChrisK 30 Jan '08

30 Jan '08

The PCRE library has just fixed a buffer overflow (related to UTF-8 mode). There are several haskell wrappers for the pcre library. If you use a wrapper for the PCRE library (libpcre) then you may want to upgrade the underlying library. http://pcre.org/news.txt states: > News about PCRE releases > ------------------------ > > Release 7.6 28-Jan-08 > --------------------- > > The main reason for having this release so soon after 7.5 is because it fixes a > potential buffer overflow problem in pcre_compile() when run in UTF-8 mode. In > addition, the CMake configuration files have been brought up to date. Cheers, Chris

1 0

Integrating editline with ghc
by Judah Jacobson 29 Jan '08

29 Jan '08

Hi all, I have managed to build ghc using the initial release of the editline package: Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline). Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following: - Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline. Does that sound like the right way to handle this? If so, I'll send a darcs patch. Also, should editline be made a boot-package or an extra-package (or neither)? Thanks, -Judah

12 48

filepath
by Ian Lynagh 28 Jan '08

28 Jan '08

Hi Neil, I'm having some problems using filepath in GHC. I think some of these we might have discussed before, but if so I've forgotten what the conclusion was, if any, and I can't see the answers in the docs. The first is this: Prelude System.FilePath> "." </> "foo" "./foo" which means we get things like [2 of 2] Compiling GHC.Foo ( ./GHC/Foo.hs, ./GHC/Foo.o ) rather than [2 of 2] Compiling GHC.Foo ( GHC/Foo.hs, GHC/Foo.o ) Is there a reason the result shouldn't be "foo"? Possibly relatedly, the current directory seems to be "" rather than ".". This turns up in at least a couple of areas: Prelude System.FilePath> normalise "." "" Prelude System.FilePath> splitFileName "foo" ("","foo") I expected "." and "./" respectively, rather than the ""s. This causes problems when giving arguments to library functions or programs, which generally want "." or "./" rather than "", and if you are displaying a directory to the user then you again probably don't want to print "". As an example, I had a problem where GHC was running "gcc -I foo" rather than "gcc -I. foo". This looks like a straightforward bug to me: Prelude System.FilePath> normalise "./" "/" I'm not convinced by Prelude System.FilePath> isValid "" True I don't think I could "create a file like it". Finally, could splitSearchPath please take an extra argument, a list of FilePaths, to be appended to the result if it ends with a : or ; (as appropriate)? Thanks Ian

13 34

Quick Hackage question
by Adrian Hey 26 Jan '08

26 Jan '08

Hello, Could someone explain why some packages in Hackage have links to the haddock for exposed modules and others don't? Also some seem to have links to a "buildlog", but others don't. What's going on? Thanks -- Adrian Hey

5 12

Re: Network.CGI changes
by Björn Bringert 25 Jan '08

25 Jan '08

Hi Frederik, (I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in the cgi package can shout.) That exact module actually used to exist in the cgi package as well (it implemented the complete API of the old Network.CGI), but after a few releases I removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain. The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI. I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs /Björn Frederik Eaton wrote: > Dear Johannes, > > Thanks, that works for me. > > Bjorn, perhaps it would be easier to put these five lines in a module > (Network.CGI.Compat?) in the new package, rather than having people > maintain and download a separate cgi-compat package? Perhaps the two > other functions in the old CGI interface can be implemented in terms > of the new API as well? > > Best wishes, > > Frederik > > On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: >> If you need the old "wrapper" function, then use something like this: >> >> wrapper :: ([(String,String)] -> IO Html) -> IO () >> wrapper f = runCGI $ do >> >> e <- getInputs >> a <- lift $ f $ e >> output $ renderHtml a >> >> best regards, Johannes Waldmann. >> >

3 3