- Libraries - Haskell.org

Using newtypes or any data with unboxed Vectors
by Ken Bateman 12 Jul '15

12 Jul '15

I think I've managed to come up with an easy, useful, and sound way for mere mortals to use unboxed vectors with arbitrary datatypes, without using template Haskell. I had a need for this capability, googled about it, and I didn't find a satisfying way to do it. This technique seemed useful and simple enough to go into the vector library, but there's so much stuff going on in there I'm not ready to submit a patch. A user just needs to create an UnboxEquivalent instance for their type, and then they can work with what looks and acts like a vector of their type, but is in fact backed by a newtype-wrapped unboxed vector of the equivalent type. newtype SmallPos = Pos Int deriving (Eq, Ord, Show) smallPos :: Int -> SmallPos smallPos x | x > 0 && x < 100 = Pos x | otherwise = error "bad SmallPos" instance UnboxEquivalent SmallPos where type UnboxEquiv SmallPos = Word8 toUnbox (Pos x) = fromIntegral x fromUnbox x = (Pos (fromIntegral x)) test1 :: EVector SmallPos test1 = Data.Vector.Generic.fromList $ map smallPos [5..15] UnboxEquivalent.hs is at http://lpaste.net/136381 Some really simple test code is at http://lpaste.net/136382 I haven't performance tested it, or stuck {-# INLINE #-} annotations in, but I think everything should be optimizing away to nothing, except of course for the toUnbox and fromUnbox calls. What do you think? -Ken

2 1

Abstract FilePath Proposal
by Herbert Valerio Riedel 10 Jul '15

10 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello *, What? ===== We (see From: & CC: headers) propose, plain and simple, to turn the currently defined type-synonym type FilePath = String into an abstract/opaque data type instead. Why/How/When? ============= For details (including motivation and a suggested transition scheme) please consult https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath Suggested discussion period: 4 weeks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526 YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5 KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+ NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb HjIPRrJbVK9AABo4AZ/Y =lg0o -----END PGP SIGNATURE-----

26 42

Generalizing replicateM?
by Fumiaki Kinoshita 08 Jul '15

08 Jul '15

I noticed that traceM is generalized to use Applicative. Then, how about replicateM/replicateM_? I don't quite like confusing names, but is better than needlessly restrictive.

5 5

Re: Generalizing replicateM?
by Ryan Scott 07 Jul '15

07 Jul '15

It looks like M Farkas-Dyck submitted a patch to generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, and replicateM_ to use Applicative instead of Monad: https://ghc.haskell.org/trac/ghc/ticket/10168. Also, +1 on the suggestion. Let's tie up the loose ends of the AMP now that's it's official.

2 1

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2
by Mark Lentczner 07 Jul '15

07 Jul '15

In concert, Haskell Platform 7.10.2 RC2 is out (for OS X and Linux - Windows on its way). You can find it here: http://www.ozonehouse.com/mark/platform/ Only minor changes since RC1: - version bumps to hashable, HTTP, OpenGLRaw, and cabal-install - closed issues #160 (typography), #157 (add --hoogle flag), #151 (OS X installer issue) sha256 sums: 326e933feb71acc0485c9fa63708505dd78322fbf009712286c5b65ee2374cdf ghc-7.10.1.20150630-x86_64-apple-darwin.tar.bz2 606d458a0809f64933bdf132af42979e4b44209900eea6649caf2927cd449835 haskell-platform-7.10.1.20150630-src.tar.gz 4c25593e04d55e742b60f82c9d8fe2e03490efb6381792198de42789ee817300 haskell-platform-7.10.1.20150630-x86_64-unknown-linux-deb7.tar.gz 1a08b041731a02004eeb21811b83ecca212cd8e2587fe97b472abf8789aef83e Haskell Platform 7.10.1.20150630 64bit-signed.pkg — Mark

3 4

Re: Abstract FilePath Proposal
by Boespflug, Mathieu 05 Jul '15

05 Jul '15

On 28 June 2015 at 16:34, Sven Panne <svenpanne(a)gmail.com> wrote: > 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <m(a)tweag.io>: >> >> why does the proposal *not* include normalization? [...] > > > I think this is intentional, because otherwise we are in the IO monad for > basically all operations. What's the normalized representation of > "foo/bar/../baz"? Notice that the kind of normalization I'm talking about, specified in the link I provided, does not include this kind of normalization. Because it requires the IO monad to perform correctly, and only on real paths. Here is the link again: https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-P… Full canonicalization of paths, stripping out redundant ".." and whatnot, should certainly be done in a separate function, in IO.

5 5

Missing instance declarations in base
by Fumiaki Kinoshita 30 Jun '15

30 Jun '15

I found some missing instances in the base package. The instances below are almost unique by parametricity. Data.Complex: instance Functor Complex instance Applicative Complex instance Foldable Complex -- real first instance Traversable Complex Data.Functor.Identity: instance Monoid a => Monoid (Identity a) Control.Applicative: instance Foldable ZipList instance Traversable ZipList I'm going to write a patch if there is no issue with them. Also, I wonder if () could be Storable: instance Storable () where sizeOf _ = 0 alignment _ = 1 peek _ = return () poke _ _ = return ()

8 15

haskell-src-exts maintenance
by Matthew Pickering 29 Jun '15

29 Jun '15

Dear List, There are a large number of untriaged pull requests and issues currently open on the issue tracker for haskell-src-exts. The tool is widely used by tool writers but the last commit to the project is now over 6 months ago. I think it is important to get this work merged and update the parser to support modern language features introduced in GHC 7.8 and 7.10. I would personally be capable of helping with this effort but before doing so I would appreciate a comment from the current maintainers as to the current status of the project. So, 1. Does anyone know if Niklas or Peter plan to return to the project? 2. Is there anyone else who is interested in updating the HSE parser? Matt

1 0

Re: Abstract FilePath Proposal
by Herbert Valerio Riedel 27 Jun '15

27 Jun '15

On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote: [...] > I am *entirely* behind this in priciple and if it doesn't break too much > of Hackage, also in practice, but... > > ... how much of Hackage *does* this break? This won't be for free: I expect most packages which currently do more than just opaquely pass around FilePaths to require fixes. Some examples: - `writeFile "doo/foo.bar" ...` `_ <- readFile ("doo" </> "foo" <.> "bar")` This will break unless -XOverloadedStrings happens to be enabled - Unless we generalise (++) to (<>), all cases where `FilePath`s are concatenated via (++) will break. - Code that uses Data.List rather than the `filepath` package for FilePath manipulation will need fixups (simplest fix: explicitly convert to/from String for the manipulation) - Some code, like e.g. fnames <- System.Environment.getArgs forM fnames $ \fn -> print =<< readFile fn will inevitably need to insert explicit conversions to/from FilePaths I tried to simulate the effect on Hackage, but this turned out to be more time-demanding than I hoped for and I had to abort. But the above is what I encountered in my attempt. > The reason that I'm in favor in principle is that paths really *are* > opaque things -- platforms have entirely different conventions. AFAICT > the only thing that they seem to agree on is that there is a "hierarchy" > of some sort. (And not much else, including such things as case > (in-)sensivity or character sets.). > For example, in POSIX they're just strings of bytes without any > specified encoding, and I'd love if they could be make to work like > that when dealing with files in Haskell. Yes, if you look e.g. at http://hackage.haskell.org/package/unix you see a lot of API duplication, which wouldn't have been needed if FilePath was an opaque type w/ lossless conversion to/from ByteString.

4 3

Cabal cannot resolve dependencies for my Yesod website
by Philip White 24 Jun '15

24 Jun '15

Hello, all, I am trying to make the next big thing with Yesod -- but for now, just a Hello World website. After getting it running locally, I tried to integrate it with Circle CI, which has support for cabal-based Haskell projects. Circle CI runs the following commands: cabal sandbox init cabal install --upgrade-dependencies --constraint="template-haskell installed" --dependencies-only --enable-tests With this invocation, cabal cannot resolve dependencies no matter how I change the cabal config. If, however, I run just `cabal install`, everything works. This cabal failure occurs both on a CircleCI host and my laptop exactly the same way, so I know it's not my environment. I wrote a StackOverflow question with more details: http://stackoverflow.com/questions/31010999/cabal-cannot-resolve-dependenci… The github repo, for ease of reproducing the problem: https://github.com/philipmw/yesod-website I hope that someone on the list is able to help. Thanks. -- Philip

3 3