- Libraries - Haskell.org

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

Haskell Platform 2014.2.0.0 Release Candidate 3
by Mark Lentczner 31 Jul '14

31 Jul '14

Small update to the Haskell Platfrom 2014.2.0.0 release: We have new Release Candidate 3 versions of the source tarball... and a new generic-linux bindist of the platform! - source tarball: haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-srcdist…> - generic linux: haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-unknown…> *Windows and OS X users: There are no RC3 versions - as the RC2 versions seem to be holding up fine!* *General* - hptool (and hence ./platform.sh script) take a new --prefix parameter that is used for generic (non-OS X, non-Windows) builds: It sets the root under which haskell installations are located. Defaults to /usr/local/haskell. Everything will be placed in a directory named ghc-7.8.3-<arch> under this prefix. - activate-hs script for default Posix-like builds - small fixes to allow bootstrapping the platform with GHC 7.4 - README and LICENSE updated *Source Tarball* - all missing pieces now present - build platfrom from source tarball verified *Generic Linux Binary Dist* - Built from the GHC's generic Linux bindist for Deb 7 style systems - Complete tarball: this is all you need to install Haskell on a compatible system - Built on Ubuntu 12.04LTS - Tested on Ubuntu 14 - my system needed a symlink from libgmp.so to libgmp.so.10 - this seems to be an issue with the GHC bindist built components To install this: cd / sudo tar xvf ~/haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz sudo /usr/local/haskell/ghc-7.8.3-x8_64/bin/activate-hs This will finish the package registration, and install symlinks from /usr/local/bin for all the standard haskell command line tools. — Mark *shasum -a 256:* ab759ec50618f2604163eca7ad07e50c8292398a2d043fdc1012df161b2eb89a haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz 0da6879ae657481849e7ec4e5d3c4c035e090824167f97434b48af297ec17cf9 haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz

1 0

RE: Overlapping and incoherent instances
by Niklas Haas 30 Jul '14

30 Jul '14

On Tue, 29 Jul 2014 16:29:45 +0000, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > CAN_OVERLAP and CAN_BE_OVERLAPPED? > > (instead of OVERLAPPING and OVERLAPPABLE) > > Or CAN-OVERLAP, CAN-BE-OVERLAPPED > > That’s ok with me if that’s what you all want! > > Simon For my 2¢, I think OVERLAPPING and OVERLAPPABLE are just fine - I immediately understood what each word meant, there's no ugly ‘_’ or ‘-’ to agonize about for eternity. I would be +1 on just keeping those names as-is. I'm neutral about whether or not I like OVERLAPS as a combination of both, I don't think that communicates quite clearly what's going on - but I do think it's important to have a way to not have to write both lengthy pragmas out.

2 1

inits in stream-fusion
by David Feuer 30 Jul '14

30 Jul '14

The inits function in the stream-fusion package has the same very bad performance bug as the one in base/Data.List. Presumably a similar fix should work, but some adjustments may be desirable--I don't know enough about the framework to say. David Feuer

1 0