July 2008 - Libraries

Text.JSON Questions
by R Hayes 29 Jul '08

29 Jul '08

I'm using Haskell to build a web services client. The API uses JSON, so I've been playing around with Text.JSON. Text.JSON works, but it seems kind of clumsy to me. I suspect that it's my failure to understand the proper usage pattern, rather than an issue with the design. For much of what I'm doing, I don't know *exactly* what I'm going to get back. I know that there will be specific JSON fields I'm interested in, but there may be ones I'm not expecting. Writing a readJSON for a pre-designed data structure is not the right answer. I'm not marshalling and un-marshalling structures that originate in Haskell. The structures I am un-marshalling are subject to extension. it seems like the default invocation of decode is something like: (decode aString) :: Result JSValue Is that correct? I'm unclear on the design goals of parameterizing JSObject. Why isn't JSObject just a list of (String,JSValue) tuples? What do we get from parameterizing it? What's the intent of having JSObject as a data constructor for JSValue and as a distinct type constructor (whose hidden data constructor is JSONObject)? What do we get from this? Why hide JSONObject? The way things are constructed, we always end up with two layers of data constructors for JSON objects JSObject (JSONObject ...). What do we get from this additional complexity. -r hayes

4 3

Data.Time.Clock.DiffTime documentation error
by Alexander Dunlap 29 Jul '08

29 Jul '08

Hi all, The documentation for Data.Time.Clock.DiffTime says that DiffTime has an *accuracy* of 10^-12 seconds. Since (I assume) the datatype can't ensure the accuracy of external timekeeping mechanisms, shouldn't this say *precision* of 10^-12 seconds? The same is true for NominalDiffTime. I don't know if a change this simple needs to go though the Library Submissions Process, but it certainly could. Alex

2 1

#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