- Libraries - Haskell.org

#2309: containers: specialize functions that fail in a Monad to Maybe
by Ross Paterson 28 Jul '08

28 Jul '08

Several functions on containers used to have types like lookup :: (Ord k) => k -> Map k a -> Maybe a but these were generalized to lookup :: (Monad m, Ord k) => k -> Map k a -> m a The only methods of Monad used are return and fail. The problem is that, depending on the monad, fail can be an ordinary value or a runtime error: this device makes it harder to check whether a program is safe, because it hides possible runtime errors among testable conditions. The proposal is to change these signatures back, specializing them to Maybe. The functions involved are: lookup :: Ord k => k -> Map k a -> Maybe a lookupIndex :: Ord k => k -> Map k a -> Maybe Int minViewWithKey :: Map k a -> Maybe ((k,a), Map k a) maxViewWithKey :: Map k a -> Maybe ((k,a), Map k a) minView :: Map k a -> Maybe (a, Map k a) maxView :: Map k a -> Maybe (a, Map k a) lookup :: Key -> IntMap a -> Maybe a maxViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a) minViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a) maxView :: IntMap a -> Maybe (a, IntMap a) minView :: IntMap a -> Maybe (a, IntMap a) minView :: Set a -> Maybe (a, Set a) maxView :: Set a -> Maybe (a, Set a) maxView :: IntSet -> Maybe (Int, IntSet) minView :: IntSet -> Maybe (Int, IntSet) No information is lost, because in each case there is a single failure mode.

21 37

Cabal-Install Update Problems
by Jeff Wheeler 28 Jul '08

28 Jul '08

Hi, I'm trying to use cabal-install on two machines, Debian Sid and OS X 10.5, but I am unable to run "update" on either. Most other commands seem to work fine, but the networking for "update" gives an error on both machines, completely independently: Downloading package list from server 'http://hackage.haskell.org/packages/archive' cabal: recv: resource vanished (Connection reset by peer) Both machines are using a vanilla Netgear ProSafe VPN Firewall FVS318v3, a very simple prosumer router. Obviously, the router works fine for everything else, and has been running flawlessly for ages. This is using cabal-install from darcs and the cabal 1.4 branch. Thanks a bunch for helping, Jeff Wheeler

3 5

Strictness of enumFrom* on numeric types.
by Dan Doel 25 Jul '08

25 Jul '08

Greetings, As happens periodically, someone in #haskell brought up the following code snippet: [1..] !! 1000000 :: Integer When evaluated, that causes a stack overflow, because enumFrom currently returns a list of increasingly nested thunks for Integers (and Floats and Doubles...). The ensuing discussion, however, brought something I hadn't seen before to light: this shouldn't (I think) be the case, per the Haskell 98 report. In the section "Predefined Types and Classes", it is specified: For all four of these Prelude numeric types, all of the enumFrom family of functions are strict in all their arguments. Which would, I believe, have the side effect of making a straightforward implementation of the functions element-strict, thus preventing the stack overflows (to confuse matters, the later reference implementation of the functions for Floats and Doubles in instead non-strict, but that can probably be looked at as a bug in the report). Currently, I believe only Int (of the four listed in the report) has a proper implementation for all the functions. For instance length (take 3 (enumFrom undefined)) is undefined for Ints, but is 3 for Integers, Floats and Doubles, so that at least is a bug. enumFrom*To are, of course, correct by necessity. Anyhow, given the above text in the report, it seems reasonable to me to make the functions stricter for the above types (and any Ints and Words of various lengths if they have similar problems). There is, in fact a trac ticket for that: http://hackage.haskell.org/trac/ghc/ticket/1997 and a patch, evidently. But dons thought it would be appropriate to alert this list, as well (it is the maintainer, after all). Thanks for your time, -- Dan Doel

1 0

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 21 Jul '08

21 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 20 Jul '08

20 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