- Libraries - Haskell.org

Can we move bytestring to github?
by Bryan O'Sullivan 07 Mar '13

07 Mar '13

Hi, Duncan - The subject says it all. I'd like to contribute some patches to bytestring, but darcs is a big wall at this point, and the package has no bug tracker. I'd like to move it under http://github.com/haskell, a place that has served several of our core packages well. I know you're fond of darcs, but it's well established by experience that we'll get many more contributions (both patches and problem reports) on github. So... pretty pretty please.

16 25

RE: new-typeable, new cast?
by Simon Peyton-Jones 04 Mar '13

04 Mar '13

ok good. Since this is in the intersection of singletons and Typeable, I wonder if Pedro and Richard might together lead on driving this to a conclusion and implementing it? Simon | -----Original Message----- | From: Stephanie Weirich [mailto:sweirich@cis.upenn.edu] | Sent: 04 March 2013 14:24 | To: Shachaf Ben-Kiki | Cc: Simon Peyton-Jones; libraries(a)haskell.org; Richard Eisenberg | (eir(a)cis.upenn.edu) Dimitrios Vytiniotis; Iavor Diatchki; Conor | McBride; Pedro Magalhães | Subject: Re: new-typeable, new cast? | | Nice! I agree that having a (poly-kinded!) function of type | | >> eqT :: forall (a :: k) (b :: k). (Typeable a, Typeable b) => Maybe (a | >> :~: b) | | around is The Right Way to Go. I'd call this function "eqT" or | "eqTypeable", after the similar operation in Data.Type.Equality. Thanks | for pointing out that we can get such a function so easily from gcast. | (Note that gcast itself can be polykinded now, I'm writing down the | kinds to make them obvious.) | | gcast :: forall (a :: k) (b::k) (c::k ->*). (Typeable a, Typeable b) -> | c a -> Maybe (c b) | | WRT to gcast1 and gcast2, these functions can be subsumed by eqT, but | not by polykinded gcast due to the restrictions on higher-order | polymorphism. | | gcast1 can convert [b Int] to [Maybe Int], but gcast cannot. eqT can do | so with a pattern match. This behavior does seem rather special-purpose | though---eqT is much more flexible. | | With singletons, we could imagine two different polykinded operations, | that differ only in whether their arguments are explicit/implicit. | | eqTypeable :: (Typeable a, Typeable b) => Maybe (a :~: b) | | eqSing :: Sing a -> Sing b -> Maybe (a :~: b) | | Again, Sing should be kind-indexed, so that we can have Sing True, Sing | 0, and (eventually) Sing Int. | | --Stephanie | | | On Mar 4, 2013, at 8:46 AM, Shachaf Ben-Kiki wrote: | | > On Mon, Mar 4, 2013 at 4:24 AM, Simon Peyton-Jones | > <simonpj(a)microsoft.com> wrote: | >> | λ> data a :~: b where Refl :: a :~: a | >> | λ> :t gcast Refl | >> | gcast Refl :: forall a b. (Typeable a, Typeable b) => Maybe | >> | ((:~:) * a b) | >> | >> That is a ferociously-unintuitive use of 'gcast'! It too me dome | while to convince myself that it was right. Though it does indeed | work. I'd see (gcast Refl) as the primitive, with 'gcast' itself as a | simple derived function. | >> | >> I'm not sure what name to give the new cast function | >> ?? :: Typeable a, Typeable b) => Maybe (a :~: b) | >> | >> | >> Do we need gcast1 and gcast2 any more, in our new polykinded world? | Can they be depreceated? | >> | >> Simon | >> | > | > A couple of people have suggested "same". (I wonder if this would also | > subsume eqSingNat/eqSingSym?). | > | > By the way -- since (:~:) seems to be in HEAD now, but not yet | > released, is there a chance of renaming it? ":~:" is pretty awkward to | > type, given all the new TypeOperators options these days; how about | > "=="? | > | > Shachaf | >

2 1

new-typeable, new cast?
by Shachaf Ben-Kiki 04 Mar '13

04 Mar '13

This came up in #haskell -- rather than just provide coerce, cast (or a primitive that cast can be built on, as well as other things) can give a type equality witness of some kind. Some possible signatures are: cast :: (Typeable a, Typeable b) => Maybe (p a -> p b) -- Leibniz-style equality cast :: (Typeable a, Typeable b) => p a -> Maybe (p b) -- another form cast :: (Typeable a, Typeable b) => Maybe (Is a b) -- GADT-style equality cast :: (Typeable a, Typeable b) => MightBe a b -- another form -- With data Is a b where { Refl :: Is a a } -- standard equality GADT data MightBe a b where -- version with built-in Maybe, for more convenient types Is :: MightBe a a Isn't :: MightBe a b Any of these lets you write any of the other ones, of course. But "cast" doesn't let you write any of them, because it only goes in one direction. The GADT form can let you write code like foo :: forall a. Typeable a => a -> ... foo x | Is <- cast :: MightBe a Int = ...x... | Is <- cast :: MightBe a Char = ...x... | otherwise = ... Without coming up with a new name for x. It's possible to provide other functions on top of this primitive, like cast :: (Typeable a, Typeable b) => proxy a -> qroxy b -> ... -- to save some type annotations cast :: (Typeable a, Typeable b) => (a ~ b => r) -> Maybe r -- to use an expression directly cast :: (Typeable a, Typeable b) => a -> Maybe b -- the original Of the primitives I mentioned, the first two are H2010. The last two are nice to use directly, but use extensions (this probably doesn't matter so much for new-typeable). The Maybe form lets you say things like `fmap (\Is -> ...) (cast :: ...)` -- unfortunately, there's no "proper" Is type in base right now. The fourth version might save some typing, and might be slightly better performance-wise, since it saves a ⊥ (it's just represented like Bool at runtime)? Probably it all gets inlined so that doesn't matter anyway. Regardless of which particular primitive is used, it would be great for new-typeable to provide something stronger than cast. Shachaf

3 6

Continuous builds for bytestring
by Bryan O'Sullivan 03 Mar '13

03 Mar '13

We now run the build and test suite after every push to github. If something breaks, I'll be nagged. You'll need to click through a self-signed SSL cert warning from your browser: https://jenkins.serpentine.com/job/bytestring/

4 4

ANN: sandi 0.2 - reasonbly fast data encoding library
by Magnus Therning 02 Mar '13

02 Mar '13

I've just uploaded sandi version 0.2[1] to Hackage. Sandi is a data encoding library. It's aimed to be the successor of dataenc, my old data encoding library. Currently the following encodings are supported: - base16 - base32 - base32 hex - base64 - base64 url - base85 - quoted printable - uu - xx - yenc The main changes since the previous release: - Added benchmarks using criterion. - Modified API to make it better suited for piecemeal decoding by making decoding of base16, qp, and yenc accept correct but incomplete input. - Add a completely new API to allow using sandi with conduit. [1]: http://hackage.haskell.org/package/sandi-0.2 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

1 0

Re: Storable (Complex a)
by wren ng thornton 27 Feb '13

27 Feb '13

On 2/24/13 9:47 PM, Edward Kmett wrote: > I for one would be a +1 for just putting the instance in. If someone really > needs an alternative encoding to the one every one else uses they could use > a newtype. That is what they are for. +1. Since most other languages use the same encoding, and we have no especial reason to dislike that encoding, having that as the default instance makes sense. We can just use a newtype for the Matlab encoding if people really need it. -- Live well, ~wren

2 1

Storable (Complex a)
by Joachim Breitner 25 Feb '13

25 Feb '13

Hi, I noticed http://hackage.haskell.org/package/storable-complex on hackage. To avoid library proliferation, is there a chance to get this instance into base? Jed, would you be interested in getting a proper http://www.haskell.org/haskellwiki/Library_submissions process on the way? Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

4 3

aeson-fixed
by Jeff Shaw 23 Feb '13

23 Feb '13

Hello Haskellers, I disliked Aeson's use of floating point numbers when JSON included decimal numbers, since I was working on a financial application. I created a version that used Decimal, but then I changed my mind and made yet another version that used Fixed. I haven't got it in a state worthy of Hackage, but you can check it out on github. https://github.com/shawjef3/aeson You can go back a commit to get the Decimal version. Enjoy! Jeff

1 0

Suggestin: IO companion for readMaybe
by Merijn Verstraaten 23 Feb '13

23 Feb '13

L.S., Now that GHC exports "readMaybe :: Read a => String -> Maybe a" from Text.Read (which I think should be exported from a more obvious/newbie friendly place, btw. Maybe Prelude?) I'd like to propose a similar companion for "readLn :: Read a => IO a" along the lines of "maybeReadLn :: Read a => IO (Maybe a)". This would be very convenient for quick hacks and to get newcomers playing with IO without having to bother with handling exceptions from misparses of readLn. I'm not sure about the name, some options are: readLnMaybe, readMaybeLn, maybeReadLn Kind regards, Merijn

2 1

__NHC__ ifdefs in the core libraries
by Ian Lynagh 16 Feb '13

16 Feb '13

Hi all, There are a couple of hundred ifdefs for __NHC__ in the core libraries, but as far as I know nhc/yhc never switched over to the git repositories for these libraries, and in any case I believe they are now considered unmaintained projects. Even if someone decides to resurrect them, it looks like most of the ifdefs represent bugs that ought to be fixed (for example, Word being a type synonym, [] needing to be im/exported, and an instance export bug). Meanwhile, they make life harder for people working on the libraries: When making a change, one feels that one ought to also update the NHC alternative where appropriate, even though it has probably bitrotted already, and despite not being able to test it. So I propose that we remove all the __NHC__ ifdefs (and also base/NHC/) in the core libraries. What do you think? Thanks Ian

5 5