December 2012 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: Use time rather than old-time in directory
by Ian Lynagh 16 Sep '14

16 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Re: Proposal: Add hasBitSize to Data.Bits.Bits
by John Lato 19 Sep '13

19 Sep '13

> From: Edward Kmett <ekmett(a)gmail.com> > > On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <igloo(a)earth.li> wrote: > >> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote: >> > There is currently no way to know whether or not calling >> > Data.Bits.bitSizewill crash your program. >> > >> > I propose extending the Bits class to include: >> > >> > hasBitSize :: Bits b => b -> Bool >> > >> > such that it returns False for Integer and True for the other instances > > Would it be better to move bitSize into a separate class? > > > I don't think so. Ultimately, you should be able to know for every numeric > type if it has a fixed or variable number of bits. In a perfect world 'd > rather just have bitSize return a Maybe that way we don't have to truck > with partial functions in the API. > > However, the case for just adding hasBitSize is that it avoids breaking > existing code. Given that existing code using bitSize can already cause a crash when used with Integer or other infinite types, wouldn't it be better to break existing code so authors can fix (or at least examine) their use of bitSize? I'm in favor of changing the type of bitSize, although since none of my code uses that function it's an easy position for me to take. John L.

13 40

Proposal: Strict scanl, scanl1 and mapAccumL
by Bas van Dijk 18 Jul '13

18 Jul '13

Hi, Data.List exports strict versions of foldl an foldl1. I think it should also export these strict versions of scanl, scanl1 and mapAccumL: scanl' :: (a -> b -> a) -> a -> [b] -> [a] scanl' f q ls = q : (case ls of [] -> [] x:xs -> let q' = f q x in q' `seq` scanl f q' xs) scanl1' :: (a -> a -> a) -> [a] -> [a] scanl1' f (x:xs) = scanl' f x xs scanl1' _ [] = [] mapAccumL' :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y]) mapAccumL' _ s [] = (s, []) mapAccumL' f s (x:xs) = (s'',y:ys) where (s', y ) = f s x (s'',ys) = s' `seq` mapAccumL' f s' xs Is there a good reason they're not included? Discussion deadline: 2 weeks (till Monday 26 November). Regards, Bas

9 18

PolyKinds, Control.Category and GHC 7.6.1
by Edward Kmett 30 May '13

30 May '13

Would it be possible to add something like {-# LANGUAGE CPP #-} #if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 704 {-# LANGUAGE PolyKinds #-} #endif to the top of Control.Category before the 7.6.1 final release? Control.Category.Category is pretty much the only type in base that directly benefits from PolyKinds without any code changes, but without enabling the extension there nobody can define categories for kinds other than *, and most interesting categories actually have more exotic kinds. I only noticed that it wasn't there in the release candidate just now. -Edward Kmett

5 11

instance Applicative Data.Map
by Henning Thielemann 17 Mar '13

17 Mar '13

An ZipList-like Applicative instance for Data.Map would be nice. I have an application where I like to write liftA3 f amap bmap cmap meaning Map.intersectionWith ($) (Map.intersectionWith f amap bmap) cmap But I cannot complete the instance implementation because there is no sensible definition for 'pure' for Data.Map. :-(

14 31

A more useful Monoid instance for Data.Map
by Daniel Peebles 13 Mar '13

13 Mar '13

Hi all, Currently Data.Map has a Monoid instance, but it's rather lossy and not as general as it could be: instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions The instance would be much nicer if it required a Monoid on v and used unionWith mappend instead of just union. The current behavior could be emulated by using First/Last as the Monoid (or ideally a semigroup, but that's or another discussion), but other more interesting Monoid instances could also be used for the values. I realize that changing instances could break code, but I'd be curious to see how many people even use the current monoid instance. Does anyone have any system for testing hypotheses like this (by typechecking a large randomized chunk of hackage or something)? It looks like the idea has been around for at least five years: http://hackage.haskell.org/trac/ghc/ticket/1460 but the proposal was abandoned, so I wanted to see if I could get people to start talking about it again. Thanks, Dan

13 29

Simple addition to Control.Arrow
by Merijn Verstraaten 17 Jan '13

17 Jan '13

I keep finding myself needing to apply functions to both elements in a tuple and now that I've started playing around with AFRP libraries I find myself applying arrows to both sides of tuples there too. As a result I would like to propose the following addition to Control.Arrow: both :: Arrow a => a b c -> a (b, b) (c, c) both = join (***) -- or if importing join from Control.Monad is undesirable both f = f *** f Why not just write "f *** f" I hear you ask? Because when f is not a trivial expression then you need to either bind it to a new name and use "newName *** newName" (which I personally dislike, because I'm terrible at coming up with names) or write "join (***) f" which I don't find a particularly appealing notation either. Kind regards, Merijn Verstraaten

3 2

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

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