- Libraries - Haskell.org

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 31 Jul '14

31 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

Re: Proposal: Add strict iterate' (and a discussion of possible new RULES)
by David Feuer 30 Jul '14

30 Jul '14

I'm pushing hard to get unfoldr fixed ASAP, and looking to take advantage of that. Specifically, I like the idea of using the fusion that (I dearly hope) will come with unfoldr to make a variety of other things fuse that currently need their own special rules. I also want to extend fusion by one or two general rules. One that looks very good is similar to the rejected foldr/cons rule, but seems somewhat less likely to cause problems while still enhancing fusion in general: {-# RULES "cons/build" forall x (g::forall b . (a->b->b)->b->b) . x : build g = build (\c n -> x `c` g c n) #-} This will allow foldr/build fusion to look past conses. So for example, foldr f q (x : build g) will be rewritten (cons/build) to foldr f q (build (\c n -> x `c` g c n)) and then (fold/build) to (\c n -> x `c` g c n) f q This reduces to f x (g f q) A discussion about foldr k z (x1:x2:x3:...:x2000:build g), a possible way to fix it, and why I don't think it's important anyway. This means the same thing as foldr k z ([x1,x2,x3,...,x2000] ++ build g) The current ++ rule rewrites this to foldr k z (augment (\c n -> foldr c n [x1,...,x2000]) (build g)) Then foldr/augment: (\c n -> foldr c n [x1,..,x2000]) k (foldr k z (build g)) Then foldr/build: (\c n -> foldr c n [x1,...,x2000]) k (g k z) Then beta reduction: foldr k (g k z) [x1,...,x2000] So to take the example from earlier, foldr f q (x : build g) is currently bad, but foldr f q ([x] ++ build g) will end up foldr f (g f q) [x] and then in this case the foldr/single rule will give f x (g f q) but if more than one element were in the list, we'd end up with a fold over the literal list (not bad in general). This suggests a fix, but one that may be difficult to implement within GHCs stage framework as is (I'm not quite sure; someone who knows more about the system may see a way to do this, but I think it wants to happen before the ++ rule, which I think happens at the beginning of time): Translate x1:x2:x3:...:build g to [x1,x2,x3,...] ++ build g Then let everything else happen as usual. I think, however, that this is probably overkill. Just implement cons/build and tell users that if they want x1:x2:x3:....:x2000:foo not to expand under foldr then they need to write [x1,x2,x3,...,x2000]++foo instead.

1 0

Re: Overlapping and incoherent instances
by Felipe Lessa 30 Jul '14

30 Jul '14

On 29-07-2014 20:41, Stephen Paul Weber wrote: >> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... > >> instance {-# OVERLAPPING #-} Show [Char] where ... > > This, to me, is an admission that developers are not going to want to turn > overlapping on globally in general, and so the current language extensions > would not make sense to get adopted into the core language at any point. > I agree with this idea, and so would second the proposal mentioned at > <http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_x…> > that a language extension that adds actual keywords to tag instances that > should be allowed to overlap be added, instead of resorting to pragmas. > This seems like an approach that could be useful in general and one could > imagine moving "past" an extension to the core language at some point, > potentially. OTOH, the pragma is mostly harmless for older GHC versions, while the keyword approach needs a preprocessor. -- Felipe.

1 0

Re: Haskell Platform 2014.2.0.0 Release Candidate 2
by Brandon Allbery 29 Jul '14

29 Jul '14

On Tue, Jul 29, 2014 at 7:45 AM, George Colpitts <george.colpitts(a)gmail.com> wrote: > Installation worked fine. However I encountered a problem that looks like > a regression, although it may be a problem with new versions of the package > I am trying to install: It's not an H-P problem; Apple's started using their BLOCKS C extension in system headers, and gtk2hsc2hs doesn't understand it. (And possibly is not using cpp properly when processing headers.) You'll need to take this up with the gtk2hs folks. #ifdef __BLOCKS__ int scandir_b(const char *, struct dirent ***, int (^)(const struct dirent *), int (^)(const struct dirent **, const struct dirent **)) __DARWIN_INODE64(scandir_b) __OSX_AVAILABLE_STARTING(__MAC_10_6, __ IPHONE_3_2); #endif /* __BLOCKS__ */ -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Haskell Platform 2014.2.0.0 Release Candidate 2
by Mark Lentczner 28 Jul '14

28 Jul '14

The long anticipated Haskell Platform 2014.2 release, including GHC 7.8.3, and numerous updated packages, is almost here! We have created "Release Candidate 2" installers for OS X and Windows, and believe, barring show stopper issues, creepers exploding, or other bizarre phenomenon, these will likely be blessed as the final in a few days time. If you would like to be an early adopter, please try 'em out... - source tarball: haskell-platform-2014.2.0.0-RC2.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-RC2.tar…> - source repo: haskell/haskell-platform at 2014.2.0.0-RC2 <https://github.com/haskell/haskell-platform/tree/2014.2.0.0-RC2> - windows 32bit: hskellPlatform-2014.2.0.0-i386-RC2-setup.exe <http://www.ozonehouse.com/mark/platform/hskellPlatform-2014.2.0.0-i386-RC2-…> - windows 64bit:hskellPlatform-2014.2.0.0-x86_64-RC2-setup.exe <http://www.ozonehouse.com/mark/platform/hskellPlatform-2014.2.0.0-x86_64-RC…> - os x 64bit: Haskell Platform 2014.2.0.0 64bit RC2.signed.pkg <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202014.2.0.0%206…> - travis-ci build: haskell/haskell-platform <https://travis-ci.org/haskell/haskell-platform> *Notes for RC2, since RC1:* *Windows* *Extra thanks to Randy Polen for burning the midnight-oil to get ths out* - removed unneeded python (et al) files from the GHC bindist for 64-bit Windows (referenced in GHC ticket #9014 <https://ghc.haskell.org/trac/ghc/ticket/9014>) - added HTML "view source" pages for the GHC packages that was missing from the GHC bindist for both 32- and 64-bit Windows. *Mac OS X* *If you installed RC1, you can remove first with the command *sudo uninstall-hs only 7.8.3 --remove *Run it without *--remove* to see what it will do before running, it if you like. In theory you can just install this one right on top of RC1.... but hasn't been tested.* - file layout on the Mac... improved slightly (again). In particular, executables are now installed directly in $prefix/bin dirs, rather than within the package dir - fix the bug with haddock master index not being updated correctly - works on 10.6! (and 10.7, 10.8, and 10.9) with gcc or clang based Xcodes - works on 10.10!!! (Yosemite, developer preview 4 release) *Source tarball* - missing sources in hptool now present - platform.sh improved somewhat (in particular, handles host cabal being pre-sandbox) *Timetable* - These can "soak" amongst the intreped on these lists for a few hours. - On Monday evening (PST) I'll announce to haskell-cafe and reddit - End of next week (from my vacation, I'll point out), we'll declare success and ship. — Mark *SHA-256 sums:* 62f39246ad95dd2aed6ece5138f6297f945d2b450f215d074820294310e0c48a Haskell Platform 2014.2.0.0 64bit RC2.signed.pkg 7c7d3585e89e1407461efea29dcaa9628c3be3c47d93a13b5a4978046375e4fd haskell-platform-2014.2.0.0-RC2.tar.gz 6eedd76aafb266d9a09baff80cd2973498ab59195c771f7cd64425d40be29c49 hskellPlatform-2014.2.0.0-i386-RC2-setup.exe b22115ed84d1f7e747d7f0b47e32e1489e4a24613d69c91df4ae32052f88b130 hskellPlatform-2014.2.0.0-x86_64-RC2-setup.exe

1 0

Issues resulting from inlining build
by David Feuer 28 Jul '14

28 Jul '14

I think I finally figured out the deeper problem behind an issue I was having getting some things to fuse fully. I'm hoping someone has a brilliant idea for getting around it. Of course, it may be that someone else has thoroughly studied the matter and determined that there's no good solution. Suppose we write crazy :: T -> [U] crazy x = some $ long $ fusion $ pipeline oops f = map f $ crazy x uhOh c n = foldr c n $ crazy Pig ohMy = take bignum $ crazy amigo When GHC compiles crazy, it rewrites the pieces of the pipeline to build/foldr forms, fuses them, and produces crazy x = build someBigFunction In then inlines build, producing crazy x = anotherBiggy So far, this looks reasonably sensible, but it's likely bad. The problem is that GHC will (rightly) conclude that `build someBigFunction` is too big to inline, and therefore the fusion will break at that boundary and we'll produce intermediate lists in the functions that use crazy. Now if we were playing the part of the compiler by hand, we would likely factor out someBigFunction and then *refrain from inlining build*. That is, we would get {-# NOINLINE crazyB #-} crazyB x = someBigFunction crazy = nonInliningBuild crazyB Since we've factored out someBigFunction into crazyB, we can now safely inline crazy itself, allowing the pipeline to continue beyond it. The problem, of course, is that when we *don't* fuse beyond, there is some performance penalty (I have not tried to measure it yet) to passing in (:) and [] at runtime instead of fixing them at compile time.

3 3

Fusion of list functions
by Simon Peyton Jones 28 Jul '14

28 Jul '14

David, and other Haskell library folk You’ve been doing lots of work on making more Prelude functions fusible – thank you! This is really a library question, so I have not been following the details of the discussion, but I hope Edward and the Core Libraries Committee have been doing so; I’m cc’ing them. I’m more than happy to help with any questions if you all get stuck. Don’t forget to update the user manual http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html#… to say which functions are good producers/consumers. Actually, it might be better instead to state this in their Haddock comments, and remove or shrink this section of the user manual instead. It’s very hard to keep it up to date. I think it pre-dates Haddock. Many thanks. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Michael Snoyman Sent: 27 July 2014 06:08 To: Carter Schonwald Cc: Haskell Libraries Subject: Re: Am I missing something about unfoldr? One I saw not too long ago was where someone created an infinite Vector and then consumed it immediately. With optimizations turned on, the intermediate Vector was fused away. With optimizations turned off, it wasn't fused away, and the program eventually crashed when it ran out of memory for holding the infinite Vector. On Sat, Jul 26, 2014 at 11:28 PM, Carter Schonwald <carter.schonwald(a)gmail.com<mailto:carter.schonwald@gmail.com>> wrote: its worth point out that many uses of fusion in haskell libs punt on preserving bottoms, that is, fusion can make *more* programs terminate. I don't have a good example off hand mind you On Sat, Jul 26, 2014 at 4:02 PM, David Feuer <david.feuer(a)gmail.com<mailto:david.feuer@gmail.com>> wrote: Hmm... I found something I missed. I need to prove that this doesn't break when the arguments to unfold use seq (if in fact it doesn't). I will have to look into it later. On Jul 26, 2014 3:34 PM, "David Feuer" <david.feuer(a)gmail.com<mailto:david.feuer@gmail.com>> wrote: The current definition: unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr f b = case f b of Just (a,new_b) -> a : unfoldr f new_b Nothing -> [] I haven't yet looked over the Core to see if GHC is able to do a worker/wrapper transformation to inline it, but we definitely want to inline it (in some appropriate phase), because doing so has the potential to erase the Maybes. It also isn't a good producer for foldr/build. However, if we (re)write it like this: unfoldrB f b c n = go b where go b = case f b of Just (a,new_b) -> a `c` go new_b Nothing -> n unfoldr f b = build (unfoldrB f b) then we get some really nice fusion: foldr c n (unfoldr f b) = foldr c n (build (unfoldrB f b)) = unfoldrB f b c n The list is gone, and there are no new closures or data structures in its place. As a side benefit, we could write groupBy as an unfoldr, and make it a somewhat better producer, especially when the groups are small. I don't *think* there's any way to make groupBy a good consumer for foldr/build, unfortunately. _______________________________________________ Libraries mailing list Libraries(a)haskell.org<mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries(a)haskell.org<mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries

1 0

Would it be a good or bad idea to make dropWhile try to fuse?
by David Feuer 26 Jul '14

26 Jul '14

As Graham Hutton describes in "A tutorial on the universality and expressiveness of fold", dropWhile p = fst . foldr go ([], []) where go x (ys, xs) = (if p x then ys else x:xs, x:xs) We can write this for real: dropWhile :: forall a . (a -> Bool) -> [a] -> [a] dropWhile p list = build dropWhile' where dropWhile' :: forall b . (a -> b -> b) -> b -> b dropWhile' c n = fst $ foldr go (n, n) list where go x (ys, xs) = let xs' = x `c` xs in (if p x then ys else xs', xs') This is generally awful, because it could copy a large portion of the list with no benefit. However, if it fuses, it will sometimes give good results. For example, compiling f m n = foldr (+) 0 $ dropWhile (<m) $ map (+1) [1..n] yields Core that does not produce a intermediate list. Does anyone have any thoughts about whether this one is worth pursuing? David Feuer

4 7