November 2012 - Libraries

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

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

RFC: Can DefaultSignature compile-time conditional APIs be regarded "benign"?
by Herbert Valerio Riedel 14 Dec '12

14 Dec '12

Dear List, After recent discussions[1][2], from which I gathered that (compile-time) conditional APIs should be avoided, I'm left wondering if a certain kind of compile-time conditional API falls into that category as well, or whether it can be classified as "benign" and should therefore be tolerated. So I'm posting this for open discussion in the hope to reach a community consensus on whether the conditional use of the "DefaultSignature" language extension in APIs should be tolerated or not (e.g. for haskell-platform packages). To this end, in the rest of this post I try to make a case for why this class of conditional APIs is harmless. ----- So what's bad about "conditional" APIs? The way I understand the issue with respect to compile-time conditional APIs which either a) omit exposed modules or exported symbols altogether based on compile-time configuration, or even worse b) export different type-signatures for the very same symbol based on compile-time configuration are "bad", as they cause problems in client code using those APIs, such as a) not being able to properly declare the dependency on specific API features being enabled in the library API in CABAL files (since CABAL only allows to depend package version numbers), b) and from the other direction, there's no simple way for the library package to advertise the conditional features currently present in the registered package. c) Moreover, if the client code wants to use symbols which depend on compile-time configuration, it either becomes non-portable and/or becomes compile-time conditional itself. Note: It should be stressed that in the latter case the client code needs to take care to *exactly* replicate the semantics of the conditional switching between the API variants as employed by the library code (which can be CPP-based and/or CABAL-based), as any mismatch may result in compile time failures. This also poses the issue on how to properly document this "meta-property" in the library API documentation. (there may be more reasons, I just listed the ones off the top of my head) On the other hand, I think that there are cases, when a compile-time conditional API is "benign", for instance when the following condition holds: a) the library package exposes a /non-essential/ API feature based only on availability of a given compiler-feature/extension, b) the conditional feature is only ever visible to the client code if the client makes use of this compiler-feature itself, and last but not least c) the semantics of the client code must not change if the client code has been made portable (with respect to the availability of the conditional feature) E.g. consider the following hypothetical class definition: class Size a where size :: a -> Int #ifdef HAS_DEFAULT_SIGNATURE default size :: Generic a => a -> Int size x = ...Generics based implementation... #endif Now, if the client code doesn't exploit the default-signature implementation, then the client code is perfectly portable, and even if the conditional API features are available they have no visible effect whatsoever. OTOH, if the client code wants to make use of the default implementation, it needs to be built with a compiler supporting the Generics language feature, and due to a) the library is guaranteed to provide the default-signature implementation as well as soon as the client is able to use it. The client-code is now deliberately non-portable (but on the other hand, the operational semantics are guaranteed to be consistent, as there's only one case to consider) Consequently, as both scenarios don't lead to problematic situations, I'd argue that there is no harm in allowing this kind of compile-time conditional APIs using the DefaultSignature language extension. ---- cheers, hvr [1]: "Proposal: Adding generics-based rnf-helper to `deepseq`" on libraries list http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17940 [2]: "[ANNOUNCE] hashable-generics" on haskell-cafe list http://comments.gmane.org/gmane.comp.lang.haskell.cafe/101323

7 12