January 2013 - Libraries

Re: Haskell Platform proposal: Add case-insensitive and Haskell 98/2010 compliance
by Henning Thielemann 14 Jan '13

14 Jan '13

On Mon, 14 Jan 2013, Ben Millwood wrote: > In response to this, I ask you: is compatibility with the platform really a > goal for your live-sequencer? Would the live-sequencer benefit particularly > from use of the case-insensitive package? Would making the case-insensitive > package Haskell2010 enable it to work with your interpreter immediately? My answer is no, and I think it is the wrong question. My point was, that case-insensitive can easily be made both Haskell98/2010 and thus improve - the same way the "split" package improved by removing the GADT when it was added to the platform. I had actual problems when trying to do something sensible with JHC. It meant that I had to inspect and "fix" a lot of packages at once before seeing anything running. Not very encouraging when you try a different compiler. FlexibleInstances are not necessary for defining instances on Strings and if a package enters the platform it is a good opportunity to fix that. Platform packages also play a role as packages where beginners look first when they want to learn how to program real-world Haskell. > That all said, I do have my own concerns with case-insensitive. Particularly, > it provides an instance FoldCase ByteString, implicitly treating ByteStrings > as text, which I believe should be discouraged. I think it should import ByteString.Char instead of ByteString.

3 4

Proposal: refactor Arrow class
by Ross Paterson 09 Jan '13

09 Jan '13

I propose to refactor the Arrow class, so that GHC's arrow notation can be a bit more general. (The module Control.Arrow itself would remain standard Haskell.) Please comment by 12th August. In detail, the proposal is to change the Arrow class from class Category a => Arrow a where arr :: (b -> c) -> a b c first :: a b c -> a (b,d) (c,d) -- various functions made methods to allow efficient specializations by introducing a new class -- | A binary type constructor that is contravariant in its first argument, -- that is, -- -- * @'premap' id a = a@ -- -- * @'premap' (f . g) a = 'premap' g ('premap' f a)@ -- class PreArrow a where premap :: (b -> b') -> a b' c -> a b c with instances instance PreArrow (->) where premap f g = g . f instance PreArrow (Kleisli m) where premap f (Kleisli g) = Kleisli (g . f) and redefining the Arrow class as class (Category a, PreArrow a) => Arrow a where arr :: (b -> c) -> a b c arr f = premap f id first :: a b c -> a (b,d) (c,d) -- rest unchanged The proposed PreArrow class has more instances than Arrow, in particular composing a PreArrow with a Functor yields another PreArrow. The principal client for the new class would be the arrow notation, as implemented in GHC. With this class, there would be a simple rule for determining which instances are needed, based on the keywords used: * all commands ("proc" and operator arguments) need PreArrow * "do" needs Arrow * "rec" needs ArrowLoop * "case" or "if" need ArrowChoice One might object that the second argument of the PreArrow class is superfluous, and this is just a complicated Contravariant class. That is true, and in semantic terms a covariant functor would be sufficient, but Haskell's type system makes it impossible to have commonality between a Contravariant class of unary type constructors and the Arrow class used by arrow notation.

6 16

Re: Proposal: splitting the network package
by Gabriel Gonzalez 09 Jan '13

09 Jan '13

I think the best action is to contact the maintainers. I imagine that most package naming disputes can be resolved this way. Forcefully renaming packages crosses a point of no return, so we should be a little bit more hesitant to invoke that option. If we do choose to rename package, though, then I think at a minimum the policy should be that: * The package authors are unreachable * There are no suitable alternative names Also, I consider a social rating system (ala Hackage 2) the proper solution to finding the "one true" package for something, not package name space conflicts.

3 2

Re: Fwd: kqueue benchmark
by Ian Lynagh 07 Jan '13

07 Jan '13

Thanks Andi! Johan, could you review and (all being well) apply please? Thanks Ian On Sat, Jan 05, 2013 at 02:16:20PM -0500, Andreas Voellmy wrote: > Hi Ian and Simon, > > As you may know, I've been working on an update to GHC's IO manager > component that substantially improves the performance and scalability (with > cores) of this component. For example, the attached graph shows the > performance of a highly simplified web server written in Haskell vs GHC 7.7 > HEAD and vs a C web server that was written to do essentially the same > thing as my Haskell web server, minus all the Haskell overhead. With my IO > manager update, we get about 2x the performance of GHC 7.7 HEAD with 1 > core, and over 20x the performance when use lots of cores. We also come > very close to the performance of the C web server. (I can give you much > more detail on the experiment if you like - just let me know). > > Actually, this Haskell web server with the IO manager update allowed me to > push linux hard enough to find an elusive bug in the linux kernel that has > existed since Linux 2.6! After finding some weird behavior with my Haskell > web server, I wrote the C web server (the one I mentioned above) to > simulate the Haskell code's use of the kernel, but only using C. After a > few weeks of work, the kernel developers found a missing memory barrier and > committed a patch to Linux: > https://github.com/torvalds/linux/commit/128dd1759d96ad36c379240f8b9463e8ac… > . > > Bryan O'Sullivan recently reviewed my commits and has suggested that I now > ask you to pull changes into GHC. My changes required two minor commits to > the main repository and lots of commits to the base library repository. > I've posted my work on github: > > main repository: > https://github.com/AndreasVoellmy/ghc-arv/tree/parallel-iomanager-reimp-2 > (last two commits) > > and base library repository: > https://github.com/AndreasVoellmy/ghc-base-arv/tree/parallel-iomanager-reim… > (all commits following 3fb1aac) > > You may not want to review all the commits in my base library repo, but it > would be great if you could look at the two commits in the main repo, > because they add a couple hooks from the RTS to the IO manager. > > Let me know if you need any more clarification or more revisions. I'm not > sure exactly what the correct protocol is for getting these changes in, so > let me know if I need to do something like open a ticket, etc. > > Cheers, > Andi > > ---------- Forwarded message ---------- > From: Bryan O'Sullivan <bos(a)serpentine.com> > Date: Fri, Jan 4, 2013 at 11:43 AM > Subject: Re: kqueue benchmark > To: Andreas Voellmy <andreas.voellmy(a)gmail.com> > Cc: Johan Tibell <johan.tibell(a)gmail.com>, Kazu Yamamoto <kazu(a)iij.ad.jp> > > > Thanks, Andi. At this point, I think you should just go ahead and ask Ian > or Simon to pull your work into the relevant ghc trees. It's looking great. > > > On Jan 4, 2013, at 8:39, Andreas Voellmy <andreas.voellmy(a)gmail.com> wrote: > > Bryan: thanks for the detailed review and comments! I've gone through all > of your comments and for almost all of them I made the change you suggested > (I.e. fixing the mistake in calling eventfd_write, improving comments, > reducing use of conditional compiles, etc.). The only exceptions were (1) > one minor tidying up change you suggested that became obsolete due to a > later change and (2) the comment on reducing the number of capabilities at > runtime. For this one, you asked whether the RTS supports it. It does > support it. You also mentioned that it seems a bit complex. I agree, but I > don't think it's too bad, so I've just left it alone. > > I also made a couple commits to address things with closeFdWith, closeFd, > and closeFd_ that I mentioned in my last email. > > I pushed a new branch here: > https://github.com/AndreasVoellmy/ghc-base-arv/tree/parallel-iomanager-reim… > > It has been rebased against the latest HEAD and includes the following new > commits: > > These address Bryan's comments: > f33364a Fix wrong type in FFI call to eventfd_write in GHC.Event.Control. > cd7e381 Avoid conditional compilation in GHC.Event.Manager. > 7af055c Undo recent change to the type of > GHC.Event.Thread.getSystemEventManager and update the commentary on this > function > > These are fixes to closeFdWith, closeFd, and closeFd_: > c925187 closeFdWith invokes callbacks only after the fd is closed. > bb015fe Tidy up GHC.Event.Thread.closeFdWith. > 879b0f1 closeFdWith closes fd after unregistering the fd with the backend. > b508e1a Update closeFd_ to avoid unnecessary backend modifications. > 44ed970 Change GHC.Event.Manager.closeFd to unregister interest in the file > with the backend. > 3622106 Avoid use of backend modifyFdOnce in Poll backend in unregisterFd_. > de608e5 Added missing wakeup in GHC.Event.Manager.closeFd_. > 639ee76 Improve comment on GHC.Event.Manager.closeFd_. > > > > On Mon, Dec 31, 2012 at 6:18 PM, Bryan O'Sullivan <bos(a)serpentine.com>wrote: > > > Last code review of 2012 finished :-) > > > > I've commented on all your commits on github. It's a very well put > > together patchset, and was easy to review. Thanks for going to the extra > > effort to make the patches small enough to be reviewable. > > > > There was only one obviously wrong commit, which I flagged. Apart from > > that, the only substantial comment I had was about the increased number of > > #ifdefs. I believe that many of those could be done away with, which would > > make the code both cleaner and more statically checkable on more platforms > > - I'll see if I can find time to confirm that theory. > > > > I'm sure you've seen that people are justifiedly rather excited about your > > work: https://twitter.com/bos31337/status/284701554458640384 > > > > Great work! > > B. > > > > On Fri, Dec 28, 2012 at 3:26 AM, Andreas Voellmy < > > andreas.voellmy(a)gmail.com> wrote: > > > >> The changes were almost entirely in the base package. You can find them > >> here: > >> > >> > >> https://github.com/AndreasVoellmy/ghc-base-arv/tree/parallel-iomanager-reim… > >> > >> I also had to add a couple of RTS hooks, so there are also two commits in > >> the main repo, which you can see here: > >> > >> https://github.com/AndreasVoellmy/ghc-arv/tree/parallel-iomanager-reimp-2 > >> > > > >

1 0

ANN: New version of pretty-show, now with Html support
by Iavor Diatchki 06 Jan '13

06 Jan '13

Hello, I've uploaded a new version of the pretty-show package (1.5) to Hackage, which provides some useful tools for inspecting Haskell data-structures. I find it quite useful while debugging. The package provides a binary and a library: the binary, named `ppsh` can take as an input a Haskell value in standard `Show` notation, and can: * Either render it to a more human readable version by adding extra white-space and newlines, thus ensuring that the result is still a valid Haskell value, or * It can render the value as an interactive Html page, which is new in this version. The library provides similar functionality but in a programatically. Also, it has some support for working with non-Showable values, by using the `PrettyVal` class, which may be derived generically. As an example, I am attaching a picture of a part of a data-structure generated with the `language-c-quote` library, by using the standard `Show` instance. I hope you find this useful, -Iavor

1 0

Network.URI - MIN_VERSION_base problem, or finger-trouble?
by Graham Klyne 05 Jan '13

05 Jan '13

A couple of problems with Network.URI have been brought to my attention, so I thought I'd have a go at seeing if I could fix them. It's been a while (years) since I used the Haskell toolchain in anger, so I'm a bit out of touch with how thinks are working now. So far, I have: 1. Installed Haskell platform (64-bit version for MacOS). 2. Checked out the 'network' project from https://github.com/haskell/network 3. cabal install test-framework 4. cabal install test-framework-hunit 5. changed to the 'test' directory of the checked out 'network' project Then when I try to run GHC, I get this error: [[ conina:tests graham$ ghc -v -XDeriveDataTypeable ../Network/URI.hs uri001.hs Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.0.4 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/package.conf.d/package.cache Using binary package database: /Users/graham/.ghc/x86_64-darwin-7.4.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-7d3c2c69a5e8257a04b2c679c40e2fa7 wired-in package integer-gmp mapped to integer-gmp-0.4.0.0-af3a28fdc4138858e0c7c5ecc2a64f43 wired-in package base mapped to base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.7.0.0-29110cc89a711d6ab3e7ee0e0a8ee949 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *../Network/URI.hs,*uri001.hs Created temporary directory: /tmp/ghc65140_0 *** C pre-processor: '/usr/bin/gcc' '-E' '-undef' '-traditional' '-m64' '-fno-stack-protector' '-m64' '-I' '/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/base-4.5.1.0/include' '-I' '/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/include' '-D__GLASGOW_HASKELL__=704' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-U __PIC__' '-D__PIC__' '-x' 'c' '../Network/URI.hs' '-o' '/tmp/ghc65140_0/ghc65140_0.hscpp' ../Network/URI.hs:135:0: error: missing binary operator before token "(" *** Deleting temp files: Deleting: /tmp/ghc65140_0/ghc65140_0.hscpp Warning: deleting non-existent /tmp/ghc65140_0/ghc65140_0.hscpp *** Deleting temp dirs: Deleting: /tmp/ghc65140_0 ]] The problem seems to be with the following lines in URI.hs (starting at line 135): [[ # if MIN_VERSION_base(4,0,0) import Data.Data (Data) # else import Data.Generics (Data) # endif ]] If I remove these lines, and just leave [[ import Data.Generics (Data) ]] I can compile and run the test suite just fine: [[ Test Cases Total Passed 319 319 Failed 0 0 Total 319 319 ]] I'm _guessing_ the problem here is something to do with "MIN_VERSION_base(4,0,0)" - not being familiar with the current build environment setup, I'm not sure where it is or should be defined, or what it is intended to mean. I did find these: * http://www.haskell.org/pipermail/haskell-cafe/2012-August/102787.html * http://stackoverflow.com/questions/8961413/zlib-build-error-with-ghc but they didn't help me. It seems there's a fix that involves using __GLASGOW_HASKELL__ instead of MIN_VERSION_base(4,0,0), but I'm not sure exactly how that would play out - or indeed if that's the correct approach for a permanent fix. Is there something else I should be doing to set up the development and test environment for this library module? Thanks for any pointers. #g --

4 4

Re: Maximum and Minimum monoids
by wren ng thornton 01 Jan '13

01 Jan '13

On 12/29/12 8:29 AM, Strake wrote:> and (Max a) and (Min a) are not properly monoids. They're monoids just fine. It's just that their identity element need not be in the set being folded over. > We could define these: > > Supr, Infi :: * -> * Please please, if we're going to abbreviate mathematical terms then we ought to stick to the standard mathematical abbreviations: sup, inf. Personally, I'm fine with Min and Max as they are, because in particular they capture the fact that we're dealing with total orders here. That is, other than for empty sets, they do in fact return the maximum/minimum. Whereas Sup and Inf bring to mind the fact that what we're dealing with is a complete lattice, which need not be a total order. While Sup and Inf make perfectly good monoids/semigroups, I'd prefer if they properly allow all complete lattices rather than being unnecessarily restricted to Ord. -- Live well, ~wren

2 2

Maximum and Minimum monoids
by Gabriel Gonzalez 01 Jan '13

01 Jan '13

I don't know if this has been brought up before or not, but would it be possible to add the Maximum and Minimum monoids to Data.Monoid? The following implementations extend the traditional semigroups using Maybe. ****** newtype Maximum a = Maximum { getMaximum :: Maybe a } instance (Ord a) => Monoid (Maximum a) where mempty = Maximum Nothing mappend (Maximum Nothing) m2 = m2 mappend m1 (Maximum Nothing) = m1 mappend (Maximum (Just a1)) (Maximum (Just a2)) = Maximum (Just (max a1 a2)) newtype Minimum a = Minimum { getMinimum :: Maybe a } instance (Ord a) => Monoid (Minimum a) where mempty = Minimum Nothing mappend (Minimum Nothing) m2 = m2 mappend m1 (Minimum Nothing) = m1 mappend (Minimum (Just a1)) (Minimum (Just a2)) = Minimum (Just (min a1 a2)) ****** These also give the correct behavior when folding empty structures by returning Nothing. The reason I'm asking is that my `pipes` library uses `WriterT` to implement folds and having the above monoids lets me implement minimum and maximum folds elegantly. I can always provide these monoids myself, but I feel like they belong in Data.Monoid.

12 24

Proposal: add conversion functions to Data.Fixed.
by Jeff Shaw 01 Jan '13

01 Jan '13

Hello, In my work I've run into an annoyance: Data.Fixed.Fixed does not have a Binary instance in the binary package. This is a result of the representation of Fixed being hidden, which is understandable. The problem is that when I want to create a Binary instance for Fixed, I need to use unsafeCoerce, which is nasty, and there's no built-in way to safely deal with problems involving the desired resolution being different when deseralizing. Today I played around with the source to Fixed, and came up with this proposed solution: - | Get a Fixed value's Integer representation and resolution. fromFixed :: (HasResolution a) => Fixed a -> (Integer,Integer) fromFixed f@(MkFixed i) = (i, resolution f) -- | Given an Integer representation and resolution of a Fixed value, -- create a new Fixed value with an arbitrary resolution. toFixed :: (HasResolution a) => (Integer,Integer) -> Fixed a toFixed (i,r0) = withResolution (\r1 -> MkFixed $ (i * r1) `div` r0) These functions lead to this useful derivation: convertFixed = toFixed . fromFixed, which leads to the possibility of having many possibly useful utility functions, such as toUni, fromUni, toDeci, fromDeci, etc. From fromFixed and toFixed, a safe instance for Binary (Fixed a) can be built (I haven't tested this, but it looks right): instance (HasResolution a) => Binary (Fixed a) where put = put . fromFixed get = get >>= return . toFixed Here is my patch: https://docs.google.com/open?id=0B8oSBVnQGD_wNGEtT1JRSnpPUms. Please respond with any comments, concerns, or ideas. Discussion period: 3 weeks. Thanks, Jeff

7 18