- Libraries - Haskell.org

Overlapping and incoherent instances
by Simon Peyton Jones 12 Aug '14

12 Aug '14

Friends One of GHC's more widely-used features is overlapping (and sometimes incoherent) instances. The user-manual documentation is here<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio…>. The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively. However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time. Using LANGUAGE OverlappingInstances simply sets the "I am an overlapping instance" flag for every instance declaration in that module. This is a Big Hammer. It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping. It brutally applies to every instance in the module. Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped. The clue might be in the command line that compiles that module! Iavor has recently implemented per-instance-declaration pragmas, so you can say instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... instance {-# OVERLAPPING #-} Show [Char] where ... This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration). This new feature will be in GHC 7.10 and I'm sure you will be happy about that. But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer. The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle. We could make that two cycles if it was helpful. However, if you want deprecation-free libraries, it will entail a wave of library updates. This email is just to warn you, and to let you yell if you think this is a bad idea. It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely - it just seems wrong not to actively push authors in the right direction. These deprecations of course popped up in the test suite, so I've been replacing them with per-instance pragmas there too. Interestingly in some cases, when looking for which instances needed the pragmas, I found...none. So OverlappingInstances was entirely unnecessary. Maybe library authors will find that too! Simon

18 36

Foldr/build fusion and reverse
by David Feuer 11 Aug '14

11 Aug '14

Currently, reverse does not participate at all. This law looks eminently exploitable: foldr c n (reverse xs) = foldl (flip c) n xs foldr c n $ reverse $ build xs =

1 0

Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by John Wiegley 11 Aug '14

11 Aug '14

1. I propose that we add the following package to base: http://hackage.haskell.org/packages/archive/semigroups/0.9.2/doc/html/Data-… This is somewhat in the spirit of the AMP proposal: further improving the correctness of our algebraic abstractions. 2. That we make Semigroup a superclass of Monoid, so that (minimally): class Semigroup a where (<>) :: a -> a -> a class Semigroup a => Monoid a where mempty :: a mconcat :: [a] -> a mconcat = foldr (<>) mempty mappend :: Semigroup a => a -> a -> a mappend = (<>) 3. (Optional, recommended) There are other useful functions that can be added to Semigroup, such as sconcat and times1p, but I will let Edward speak to whether those should be proposed at this time. 4. (Optional, recommended) That we fix the Monoid instance for Maybe to be: instance Semigroup a => Semigroup (Maybe a) where Just x <> Just y = Just (x <> y) _ <> _ = Nothing instance Semigroup a => Monoid (Maybe a) where mempty = Nothing For some clarification on what semigroups are and why we'd want to change Monoid, I excerpt here a selection from Brent Yorgey's "Monoids and Variations" paper: Semigroups A semigroup is like a monoid without the requirement of an identity element: it consists simply of a set with an associative binary operation.... Of course, any monoid is automatically a semigroup (by forgetting about its identity element). In the other direction, to turn a semigroup into a monoid, simply add a new distinguished element to serve as the identity, and extend the definition of the binary operation appropriately. This creates an identity element by definition, and it is not hard to see that it preserves associativity.... Adding a new distinguished element to a type is typically accomplished by wrapping it in Maybe. One might therefore expect to turn an instance of Semigroup into an instance of Monoid by wrapping it in Maybe. Sadly, Data.Monoid does not define semigroups, and has a Monoid instance for Maybe which requires a Monoid constraint on its argument type... This is somewhat odd: in essence, it ignores the identity element of [the type] and replaces it with a different one. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

9 9

Proposal: Add strict iterate'
by David Feuer 10 Aug '14

10 Aug '14

I think most if not all applications of iterate would prefer to accumulate strictly—iterating a constant function is not very useful and the spine of the result of iterate is always the same. Unlike unfoldr, which has enough strictness built in to allow its caller to decide whether to accumulate strictly, iterate is entirely lazy. I therefore propose: iterate' :: (a -> a) -> a -> [a] iterate' f b = unfoldr go b where go x = x `seq` Just (x, f x)

6 8

Re: Overlapping and incoherent instances
by Ben Millwood 05 Aug '14

05 Aug '14

On Sat, Aug 02, 2014 at 08:51:57PM +0100, Ben Millwood wrote: >On Sat, Aug 02, 2014 at 04:27:14PM +0100, Ben Millwood wrote: >>On Thu, Jul 31, 2014 at 07:20:31AM +0000, Simon Peyton Jones wrote: >>>My main motivation was to signal the proposed deprecation of the global per-module flag -XoverlappingInstances. Happily people generally seem fine with this. It is, after all, precisely what deprecations are for ("the old thing still works for now, but it won't do so for ever, and you should change as soon as is convenient"). >> >>Here's one concern I have with the deprecation of >>-XOverlappingInstances: I don't like overlapping instances, I find >>them confusing and weird and prefer to use code that doesn't >>include them, because they violate my expectations about how type >>classes work. When there is a single LANGUAGE pragma, that's a >>simple, easily-checkable signpost of "this code uses techniques >>that Ben doesn't understand". When it is all controlled by pragmas >>I basically have to check every instance declaration individually. >> >>On a largely unrelated note, here's another thing I don't >>understand: when is OVERLAPPABLE at one instance declaration >>preferable to using only OVERLAPPING at the instance declarations >>that overlap it? In the latter model, as long as none of the >>instances I write have pragmas, I can be sure none of them overlap. >>In the former model, any instance I write for an existing typeclass >>might overlap another instance, even if I don't want it to. Do we >>have any specific use cases in mind for OVERLAPPABLE? >>_______________________________________________ >>Libraries mailing list >>Libraries(a)haskell.org >>http://www.haskell.org/mailman/listinfo/libraries > >When I originally sent this mail I wasn't subscribed to the GHC >lists, so I went and fixed that and am now resending. Good grief, and then I sent from the wrong address. Sorry for the noise. >Addendum: I was surprised by the behaviour of overlapping instances >when I went and looked closer at it. > > {-# LANGUAGE FlexibleInstances #-} > module M where > class C a where f :: a -> a > instance C a where f x = x > instance C Int where f x = x + 1 > >I suspect many people have the intuition that NoOverlappingInstances >should forbid the above, but in fact OverlappingInstances or no only >controls instance *resolution*. I imagine you all already knew this >but I did not until I carefully reread things. > >As someone who dislikes overlapping type class instances, I am >finding them harder to avoid than I at first thought :(

2 1

Building network without MSYS [Was: Splitting Network.URI from the network package]
by Krzysztof SkrzÄ™tnicki 05 Aug '14

05 Aug '14

Hello. I consider the original proposal to be well founded and I support it. However, I started to think if there is anything we can improve about installation of network package itself? Maybe we can get rid of MSYS, at least for the end users of network package? How would that happen? The following plan came to my mind: 1. Select a single supported configuration (Windows version) 2. Execute a "normal" build with MSYS 3. Extract a configuration that was "discovered" by MSYS 4. Bake in the configuration into installation files to be used on Windows when MSYS is not present. There shouldn't be that many supported configurations on Windows. I think it is reasonable to do: 1. Windows XP 2. Windows 7 3. Windows 8 4. some Windows Server versions? For each system the variants would be: 1. 32-bit system, 32-bit GHC 2. 64-bit system, 32-bit GHC 3. 64-bit system, 64-bit GHC Right now I have done the procedure above for my own 64-bit Windows 7/32-bit GHC pair. I also added some simple logic of choosing between "Simple" build and "Configure-type" build within Setup.hs. The result is a version of network package that can be built with or without MSYS on Windows and without change on other platforms. If you want to try it it is available from Github: https://github.com/tener/network . I have also created a pull request against haskell/network you can check out: https://github.com/haskell/network/pull/141 Please let me know if you think this is a reasonable approach. -- Krzysztof On Mon, Aug 4, 2014 at 6:21 PM, Michael Snoyman <michael(a)snoyman.com> wrote: > > > > On Mon, Aug 4, 2014 at 6:55 PM, Johan Tibell <johan.tibell(a)gmail.com> > wrote: > >> Hi Michael, >> >> I'm supportive of this (just as I've been in the past). We need to >> have network-uri added to the HP, which I don't think should be a >> problem as the API doesn't change with this split, assuming that the >> new maintainer agrees to follow the HP rules (e.g. don't add non-HP >> packages as dependencies, don't radical change the API without >> discussion.) >> >> I have a slight preference to use 2.6 as the network version number, >> as I'm saving 3.0 for something more juicy. >> >> > I have no objection to 2.6 instead of 3.0. I didn't feel strongly one way > or the other, I just wanted to make the proposal as concrete as possible. > Consider it amended to use 2.6 instead. > > >> > 1. Create a new package, network-uri, version 2.5.0.0, which exposes no >> modules and has an upper bound `network < 2.6. >> >> I'm sure there's something clever behind this empty package, but I >> don't quite understand it. How does this help. Note that depending on >> network-uri but not network will not let you use Network.URI in your >> code, as that module will be hidden. >> >> > The idea is that users of Network.URI will be able to add a dependency > along the lines of: > > build-depends: network >= 2.5 && < 2.7, network-uri >= 2.5 && < 2.7 > > and work with both the pre- and post-split versions of the package, > without any conditional compilation or cabal flags. I'm sensitive to adding > any requirements of cabal flags, since (1) it clutters cabal files quite a > bit[1], and (2) we just went through some painful cabal-install dependency > solver issues around flags. > > >> > 2. Create a second release of network-uri, version 3.0.0.0, which >> provides the Network.URI module verbatim as provided by the network package >> today, and has a lower bound `network >= 3.0`. >> >> (And < X+1, as the HP follows the PVP.) >> > > I really don't want this to turn into another PVP discussion. And I'm not > going to object to including an upper bound here if that's deemed > "required" for some reason (I only left it out of the proposal since it's > irrelevant to my point). All that said... > > Can you name a single way in which an upper bound *actually* helps? > network-uri will not depend on any functionality in network itself[2], so > there's no way that a breaking change in network will possibly cause > network-uri to stop compiling. The *only* possibility is that network could > expose a module that conflicts with a module in network-uri. However: > > 1. That is not a protected situation by the PVP anyway; adding a new > module to a package is a minor version bump, so an upper bound wouldn't > provide protection. > 2. I actually think we *should* have a guarantee that network never expose > a module that conflicts with network-uri. Better yet, I think there should > be an accepted standard that no two Haskell Platform packages export the > same module name. (I'm not actually proposing that here, it's clearly > separate than my main proposal.) > > So if someone can articulate a good reason for an upper bound in > network-uri on network, please let me know. Again, if this is going to end > up blocking this proposal, I'd rather just include the upper bound. > > Michael > > [1] Two painful experiences for me were the network + network-bytestring > merge, and the blaze-html/blaze-markdown split. I'd like to try to avoid > that situation, and in my recent package merging, I've done so as much as > possible. > [2] If there *is* some dependency from the Network.URI module to the rest > of the network package, please let me know, I couldn't see one. > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >

2 2

last call... for HP 2014.2.0.0
by Mark Lentczner 05 Aug '14

05 Aug '14

As it stands, I'm planning on calling the final RCs final: - RC2 Mac - RC4 Win - RC3 Src and linux-dist They have a few wibbles, but nothing close to show-stopping. I'll rebuild the web site and upload it tomorrow and announce then as well. - Mark ("still on vacation") L.

1 0

Proposal (breaking change, but probably not one that will break any real code): strictify genericLength
by David Feuer 03 Aug '14

03 Aug '14

As far as I can tell, Haskell 2010 does not specify anything about the strictness of genericLength. Currently, it is maximally lazy. This is good, I suppose, if you want to support lists that are very long and are using floating point or some similarly broken Num instance. But this is not something many (any?) people have any interest in doing. As a result, the genericLength function is on a nice little list I found of Haskell functions one should never use. I therefore propose that we change it to something nice and simple, like genericLength = foldl' 0 (\x _ -> x + 1) Admittedly, this may not be optimal for Int8, Int16, Word8, or Word16, so we may need to use rules to rewrite these four to narrow the result of length (or some such).

4 5

Fwd: Proposal (breaking change, but probably not one that will break any real code): strictify genericLength
by David Feuer 03 Aug '14

03 Aug '14

Since Krzysztof made their replies public, I figured I'd add this reply to the mix (an expanded/improved version of a message I sent them). I think these things are worth considering however things turn out. If, for the sake of stability, genericLength has to stay (pretty much) the same, it probably wouldn't hurt to add a genericLength' or some such. As for the current genericLength, it is not a panacea even for lazy naturals. I started by noticing that the same result is achieved by the slightly nicer definition genericLength = foldr (\_ y = 1 + y) However, just looking at the definition more closely than I had reveals an efficiency problem even here. Specifically, this definition assumes that a + b is defined something like Zero + b = b Succ a + b = a + Succ b It would, however, be perfectly legitimate to do it the other way around: a + Zero = a a + Succ b = Succ a + b In the former case, 1+y is O(1) and y+1 is O(y), whereas the opposite is true in the latter case! The situation for the strict version has some subtleties too. One thing that's not subtle is that the strict version should be written using foldl' (at least in most cases), which should allow it to take advantage of the new call arity analysis and resulting optimization. As for the nitty-gritty, there are several cases to think about: 1. Int8, Int16, Word8, and Word16, where it is advantageous to calculate the length as an Int (or perhaps a Word) and then narrow the result—I'm not sure if GHC will do this right automatically in this case (and the answer could depend on whether -fllvm is used or not), but it would be best to do some benchmarking before concluding that it's okay to ignore. 2. Int32, Word32, Int64, and Word64, which will generally work well calculated directly, although it's possible that the latter two might be done better some other way on 32-bit machines. 3. Integer: it should work to calculate that as a Word64 and convert it, but then again if we wait 30 years that might not be true anymore, maybe. 4. Floating point: The current definition, as well as the one you propose, seem wrong for floating point. I would expect the floating point length of a sufficiently long list to be the closest approximation from the Word64 length, but if you tried to find the genericLength of a list with length 2^24 as a Float with these definitions, you will have a problem: they will actually get stuck at the largest exactly representable integer and go no further.

1 0

Re: Proposal (breaking change, but probably not one that will break any real code): strictify genericLength
by Krzysztof Skrzętnicki 03 Aug '14

03 Aug '14

I have realised my replies have been only sent to Davied and not to Libraries as a whole. Reply-all strikes again... Please see below for my previous posts. Sorry about that. On Sun, Aug 3, 2014 at 9:34 AM, Krzysztof Skrzętnicki <gtener(a)gmail.com> wrote: > I see. This point wasn't obvious to me before. This seems like a bug > though, given the definitions given in Data.List for genericLength. It goes: > > -- | The 'genericLength' function is an overloaded version of 'length'. In > -- particular, instead of returning an 'Int', it returns any type which is > -- an instance of 'Num'. It is, however, less efficient than 'length'. > genericLength :: (Num i) => [a] -> i > {-# NOINLINE [1] genericLength #-} > genericLength [] = 0 > genericLength (_:l) = 1 + genericLength l > > {-# RULES > "genericLengthInt" genericLength = (strictGenericLength :: [a] -> > Int); > "genericLengthInteger" genericLength = (strictGenericLength :: [a] -> > Integer); > #-} > > strictGenericLength :: (Num i) => [b] -> i > strictGenericLength l = gl l 0 > where > gl [] a = a > gl (_:xs) a = let a' = a + 1 in a' `seq` gl xs > a' > > We can see that: > 1. There is already strictGenericLength but it is simply not exported > 2. RULES replace lazy genericLength with strictGenericLength for some > Int-like types, but not for all. It is at least inconsistent. > > Given that genericLength xs == strictGenericLength xs for strict Num > types, unless the former diverges, it would make sense to expand the RULES > to more types. I wouldn't make it default for all types though... > > It would also make sense to export the already defined strictGenericLength. > > > On Sun, Aug 3, 2014 at 8:44 AM, David Feuer <david.feuer(a)gmail.com> wrote: > >> Forcing the result does not even begin to fix anything. The problem is >> that calculating the genericLength of a long list using typical number >> types will cause a stack overflow. For example, typing >> >> genericLength $ [1..(20000000::Int)] :: Int64 >> >> will lead to a stack overflow. >> >> On Sun, Aug 3, 2014 at 2:05 AM, Krzysztof Skrzętnicki <gtener(a)gmail.com> >> wrote: >> > Personally I dont see any good reason for doing this change. It will >> likely >> > break peoples code and force us to increase maintenance costs. >> > >> > *If* you want strict output you can always force the result. >> > >> > There is also an option of providing new function with semantics you >> > propose: genericLength' >> > >> > Krzysztof >> > >> > 03-08-2014 04:03, "David Feuer" <david.feuer(a)gmail.com> napisał(a): >> >> >> >> As far as I can tell, Haskell 2010 does not specify anything about the >> >> strictness of genericLength. Currently, it is maximally lazy. This is >> good, >> >> I suppose, if you want to support lists that are very long and are >> using >> >> floating point or some similarly broken Num instance. >> >> >> >> But this is not something many (any?) people have any interest in >> doing. >> >> As a result, the genericLength function is on a nice little list I >> found of >> >> Haskell functions one should never use. I therefore propose that we >> change >> >> it to something nice and simple, like >> >> >> >> genericLength = foldl' 0 (\x _ -> x + 1) >> >> >> >> Admittedly, this may not be optimal for Int8, Int16, Word8, or Word16, >> so >> >> we may need to use rules to rewrite these four to narrow the result of >> >> length (or some such). >> >> >> >> >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries(a)haskell.org >> >> http://www.haskell.org/mailman/listinfo/libraries >> >> >> > >> > >

1 0