- Libraries - Haskell.org

agreeing a policy for maintainers and hackageDB
by Ross Paterson 25 Jul '08

25 Jul '08

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are: * users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer. When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt: If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves. A Maintainer value of "none" indicates that the package is not supported. If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

18 44

Proposal: new signal-handling API
by Simon Marlow 22 Jul '08

22 Jul '08

I've just submitted a proposal for a new signal-handling API, the ticket is here: http://hackage.haskell.org/trac/ghc/ticket/2451 Deadline: 1 Aug (2 weeks). Cheers, Simon

9 20

#2391 Network.listenOn (PortNumber n) Sometimes Picks IPv6
by Curt Sampson 22 Jul '08

22 Jul '08

So this has been sitting around for a bit: http://hackage.haskell.org/trac/ghc/ticket/2391 And I'm sort of hoping we can get it resolved soon so that a fixed version is included in GHC 6.10. My basic thoughts are: 1. Listening on both IPV4 and IPV6, if I recall correctly, introduces all sorts of interesting problems, and basically, you don't want to go there. Or am I wrong about that? 2. We should default to IPv4 if someone uses the current interface, as that's what most people will be expecting, as that's the Linux (and probably Windows) behvaiour. 3. Given this, we should add a separate "PortNumber6 Int" value constructor that informs listenOn to use IPv6 instead of IPv4, so that people can use IPv6 with the simple interface. Thoughts? cjs -- Curt Sampson <cjs(a)starling-software.com> +81 90 7737 2974 Mobile sites and software consulting: http://www.starling-software.com

2 4

Proposal: Extensible exceptions
by Ian Lynagh 21 Jul '08

21 Jul '08

Hi all, This is a proposal to replace the current exception mechanism in the base library with extensible exceptions. It also reimplements the existing exceptions on top of extensible exceptions, for legacy applications. Proposed deadline: 25th July. http://hackage.haskell.org/trac/ghc/ticket/2419 === What are extensible exceptions? Simon's extensible extensions paper is very easy to read, and describes the problems and proposed solution very well: http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf I won't try to reproduce everything the paper says here, but here is the list of what we want extracted from it: * A hierarchy of exception types, such that a particular catch can choose to catch only exceptions that belong to a particular subclass and re-throw all others. * A way to add new exception types at any point in the hierarchy from library or program code. * The boilerplate code required to add a new type to the exception hierarchy should be minimal. * Exceptions should be thrown and caught using the same primitives, regardless of the types involved. I heartily recommend having a read through of the paper. === Patches and examples The patches are here: http://darcs.haskell.org/ext-excep/ I've attached Examples.hs, which gives some examples of using it. The patches aren't polished; if this proposal is accepted then there is some more work to do, moving things around inside the base package to simplify the dependencies, and to maximise the amount of code that can be shared between all the impls. There's also some GHC-specific fiddling to be done, to make GHC.TopHandler use the new exceptions. This can all be done without further library proposals, though. Also, currently it derives Data.Typeable, which is unportable, but we can easily work around that. The only extensions that I don't think that we can do without are ExistentialQuantification and Rank2Types. DeriveDataTypeable makes the implementation easier, and DeriveDataTypeable and PatternSignatures make using it easier. === Library function differences As far as the library functions are concerned, here are the main differences: The old and new types for catch are: Old: catch :: IO a -> (Exception -> IO a) -> IO a New: catch :: Exception e => IO a -> (e -> IO a) -> IO a i.e. catch can now catch any type of exception; we don't have to force all the different types of extension into one fixed datatype. All the other exception functions are similarly changed to handle any type of extension, e.g. we now have try :: Exception e => IO a -> IO (Either e a) Now that you can write handlers for different exception types, you might want to catch multiple different types at the same point. You can use catches for this. For example, the OldException module needs to catch all the new exception types and put them into the old Exception type, so that the legacy handler can be run on them. It looks like this: catch :: IO a -> (Exception -> IO a) -> IO a catch io handler = io `catches` [Handler (\e -> handler e), Handler (\exc -> handler (ArithException exc)), Handler (\exc -> handler (ArrayException exc)), ...] where the first Handler deals with exceptions of type Exception, the second those of type ArithException, and so on. If you want to catch all exceptions, e.g. if you want to cleanup and rethrow the exception, or just print the exception at the top-level, you can use the new function catchAny: catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a You can happily write `catchAny` \e -> print e where `catch` \e -> print e would give you an ambiguous type variable error. There's also ignoreExceptions :: IO () -> IO () which can be used instead of try for things like ignoreExceptions (hClose h) (where we don't look at the result, so the exception type would be ambiguous if we used try). (I'm not sure if this is the best name for this function). All the build failures I've seen with the new exceptions library have been cases where you need to change a "catch" to "catchAny", "try" to "ignoreExceptions", or occassionally a different function, e.g. "bracket" or "handle", is used to handle any extension, so adding a type signature involving the SomeException type solves the problem. The old interface is available in Control.OldException. Currently it doesn't catch exceptions that don't fit into the old Exception type; we could catch them, show them and treat them as user errors, but then the exception has changed if it gets rethrown. Thanks Ian

22 85

The NetBSD Foundation Moves to a Two Clause BSD License
by Don Stewart 21 Jul '08

21 Jul '08

NetBSD has moved from BSD-3 to BSD-2 style licenses. A similar default for the Haskell community probably also makes sense (removing the 'endorsement' clause, which doesn't make much sense in the modern software industry). The new BSD2 license is below: ------------------------------------------------------------------------ /*- * Copyright (c) 2008 The NetBSD Foundation, Inc. * All rights reserved. * * This code is derived from software contributed to The NetBSD Foundation * by * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */

3 3

Adding split/split' to Data.List, and redefining words/lines with it; also, adding replace/replaceBy
by Gwern Branwen 21 Jul '08

21 Jul '08

Hi everyone. So recently while doing some shell scripting, I found myself redefining a 'split' function (take an item and a list, and make list of lists everywhere the item appears) *yet again*, and I got annoyed enough to resolve to fix the situation. While I was at it, I decided that since 'lines' and 'words' are conceptually specializations of a general split function, I would come up with rewrites for them too; much more aesthetically satisfying to me, as it's clearer in the code now that lines and words are essentially a specialization of split, but with pragmatic edge cases (which mean we don't get nice identities like 'unlines . lines == id', but makes them more useful with, say, getContents). Code: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > lines' :: String -> [String] > lines' s = removeTrailingNull (split' '\n' s) > where > removeTrailingNull :: [String] -> [String] > removeTrailingNull y = case y of > [] -> [] > [""] -> [] > (x:xs) -> x : removeTrailingNull xs > > linesProp :: String -> Bool > linesProp x = (Prelude.lines x == lines' x) > > words' :: String -> [String] > words' = filter (not . and . map isSpace) . split isSpace > > wordsProp :: String -> Bool > wordsProp x = (Prelude.words x == words' x) > > split :: (a -> Bool) -> [a] -> [[a]] > split _ [] = [] > split p s = let (l,s') = break p s in l : case s' of > [] -> [] > (r:s'') -> [r] : split p s'' > > splitUndoProp, splitUndoIdemProp, splitPreserveDelimsProp :: (Eq a) => a -> [a] > > -> Bool > splitUndoProp x y = (concat $ split (==x) y) == y > splitUndoIdemProp x y = (concat $ concat $ split (==[x]) $ split (==x) y) == y > splitPreserveDelimsProp x y = (length $ elemIndices [x] $ split (==x) y) == > > (length $ elemIndices x y) > > split' :: (Eq a) => a -> [a] -> [[a]] > split' a b = filter (/= [a]) $ split (\x -> x==a) b > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've run many many QuickChecks testing against the Prelude lines and words, and the definitions seem to be correct. What do people think of adding these? I know I'm not the only one who has wanted split or split' on more than one occasion, and they are not the funnest functions to rewrite every time you want them. (About all they're missing are Haddocks; and perhaps a better name for split' which reflects how it is lossy and can't be undone while split can be.) ------ On a secondary note, but less important than the foregoing, I'd like to add two functions: 'replace' and 'replaceBy'. They do basically what they sound like: given two items, change every occurrence in a given list of one item to another. These are two other functions I often have to redefine, which still surprises me - Data.List has a surfeit of obscure functions I've never used and which are kind of odd, but a basic search-and-replace function isn't there? I mean, I'm not saying let's add enough functions to Data.List to turn it into a mini-Perl, but it strikes me as a real gap. (As before, I've defined some sensible QC properties and checked, although the definitions look obviously right to me.) Code: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > replaceBy :: (a -> Bool) -> a -> [a] -> [a] > replaceBy a b = map (\x -> if a x then b else x) > > replace :: (Eq a) => a -> a -> [a] -> [a] > replace a = replaceBy (==a) > > replaceLengthProp :: (Eq a) => a -> a -> [a] -> Bool > replaceLengthProp x y z = (length $ replace x y z) == (length z) > replaceUndoableProp :: (Eq a) => a -> a -> [a] -> Bool > replaceUndoableProp x y z = if not (y `elem` z) then z == (replace y x $ replace > > x y z) else True > replaceIdempotentProp :: (Eq a) => a -> a -> [a] -> Bool > replaceIdempotentProp x y z = (replace x y $ replace x y z) == (replace x y z) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- gwern PRF fritz Lon News IG Keyhole advise VFCT SITOR MDA

10 18

Extending the GSoC model
by Andrew Wagner 21 Jul '08

21 Jul '08

All, Not sure if this is the best place to suggest this, but I was wondering about the possibility of extending the model that we currently use for Google's Summer of Code. The benefits: 1.) A place to make suggestions for code you would never be able to write, and somebody else might not think of 2.) A place to see what's being worked on, but not yet done 3.) A way for people who are less confident in their haskell-foo to find mentors 4.) A way for people who are more confident in their haskell-foo to contribute without spending a ton of time hacking up actual code 5.) Overall, more (and higher-quality) libraries Thoughts? What would it take to make this happen?

1 0

darcs patch: Fix #2005 [network package]
by Judah Jacobson 20 Jul '08

20 Jul '08

The attached patch fixes Trac #2005 (getnameinfo error on mac with ipv6 addresses). The problem was caused by a failure to initialize the field sockaddr_in6.sin6_len . The initialization was only happening on NetBSD; apparently OS X needs it too. This patch sets that field if the macro SIN6_LEN is defined (which is the standard way to detect that, according to my research online and RFC 3493 (http://tools.ietf.org/html/rfc3493) -Judah Sat Jul 19 10:18:41 PDT 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * FIX #2005: Set the sockaddr_in.sin6_len field on all platforms that support it, not just NetBSD. M ./Network/Socket.hsc -1 +1

1 1

Proposal: overhaul System.Process
by Simon Marlow 18 Jul '08

18 Jul '08

I've made some improvements to System.Process that I'd like to get feedback on. Everything so far is backwards compatible in the sense that I've only added to the API - everything that was there before is still available, with the same semantics (except where bugs have been fixed). Haddock for the proposed new System.Process: http://darcs.haskell.org/~simonmar/process/System-Process.html Ticket: http://hackage.haskell.org/trac/ghc/ticket/2233 Discussion period: 4 weeks (20 May) Summary of changes: Tue Apr 22 15:02:16 PDT 2008 Simon Marlow <simonmarhaskell(a)gmail.com> * Overhall System.Process - fix #1780: pipes created by runInteractiveProcess are set close-on-exec by default - add a new, more general, form of process creation: createProcess Each of stdin, stdout and stderr may individually be taken from existing Handles or attached to new pipes. Also it has a nicer API. - add readProcess from Don Stewart's newpopen package. This function behaves like C's popen(). - Move System.Cmd.{system,rawSystem} into System.Process. Later we can depecate System.Cmd. - Don't use O_NONBLOCK for pipes, as it can confuse the process attached to the pipe (requires a fix to GHC.Handle in the base package). - move the tests from the GHC testsuite into the package itself, and add a couple more - bump the version to 2.0

13 75

Cabal: Building something from within a test hook
by Max Bolingbroke 18 Jul '08

18 Jul '08

Hi, I'd like to provide tests for my Cabal project, and would like to do so by having >another< Cabal project in a tests/ directory that is built and run by "Cabal test". I've got this far towards getting it working: """" main :: IO () main = defaultMainWithHooks (simpleUserHooks { runTests = buildAndRunTests }) buildAndRunTests :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO () buildAndRunTests _ _ _ local_build_info = do test_package_description <- fmap flattenPackageDescription $ readPackageDescription normal "./tests/test-package.cabal" let [executable] = executables test_package_description build test_package_description local_build_info defaultBuildFlags [] system $ modulePath executable """ This kind of works, but the local_build_info is obviously wrong as it is for the package being compiled rather than the one I >want< to compile. What I'm really hoping Cabal provides or is able to provide is a way to configure the tests package using the old LBI such that the same tools (e.g. compiler, hc-pkg etc) that were used for this package are used for the tests one while leaving everything else at it's default value. I could then use the resulting LBI to build the tests as I desire. Any pointers or suggestions for alternative ways I should be going about this are gratefully recieved! Max

2 2