- Libraries - Haskell.org

Re: Advance notice that I'd like to make Cabal depend on parsec
by Duncan Coutts 14 Mar '13

14 Mar '13

On Thu, 2013-03-14 at 12:22 -0300, Administrator wrote: > This GHC dependency on Cabal is putting a rather troubling constraint > in Cabal's evolution, which in my opinion is a serious problem. When I > first took a look at the dependencies between GHC and Cabal I found it > a bit strange that GHC would depend on Cabal as I would expect GHC to > be as low in the dependency tree as possible to avoid exactly these > kinds of problems. The problem is that a compiler is a rather sophisticated application and so though you'd like it to have minimal deps, it needs to do so much stuff that it ends up needing lots of deps to support its features. Things would be easier if that were not the case, and it's made harder by the fact that ghc is not just a program, but it's exposed as a library, which exposes all of its dependencies. > These GHC dependencies on Cabal are in fact small (see > http://hackage.haskell.org/trac/ghc/attachment/ticket/7740/ghc-2.png > for a summary) and with a little bit of refactoring it would be > possible to split these dependencies into a very small shared package > with minimal or no further dependencies. This would liberate Cabal to > make the necessary refactoring. Except that the bits of Cabal that ghc needs are exactly the bits that will now need parsec, text etc. The shared part would be the part that defines the InstalledPackageInfo and the parser for that. Also, though the ghc library has only relatively small dependencies on Cabal, the ghc build process uses Cabal extensively, and currently the system is that libraries that ghc needs to build get included as core libraries and shipped with ghc. That itself could change but it's also more work. > IMHO, the addition of these new dependencies to Cabal should go > together with splitting the GHC-Cabal shared dependencies into a > separate package so that there would be no additional coordination > needed from then on between these two development efforts (except when > dealing with this new package). So I would consider this if I thought it'd make a difference. In particular at some point we'll want to split the Cabal lib into the bit that just defines types and parsers etc, and the part that is a build system. But even that wouldn't save us any dependencies in this situation. Duncan

1 0

A more useful Monoid instance for Data.Map
by Daniel Peebles 13 Mar '13

13 Mar '13

Hi all, Currently Data.Map has a Monoid instance, but it's rather lossy and not as general as it could be: instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions The instance would be much nicer if it required a Monoid on v and used unionWith mappend instead of just union. The current behavior could be emulated by using First/Last as the Monoid (or ideally a semigroup, but that's or another discussion), but other more interesting Monoid instances could also be used for the values. I realize that changing instances could break code, but I'd be curious to see how many people even use the current monoid instance. Does anyone have any system for testing hypotheses like this (by typechecking a large randomized chunk of hackage or something)? It looks like the idea has been around for at least five years: http://hackage.haskell.org/trac/ghc/ticket/1460 but the proposal was abandoned, so I wanted to see if I could get people to start talking about it again. Thanks, Dan

13 29

Re: A more useful Monoid instance for Data.Map
by Gabriel Gonzalez 12 Mar '13

12 Mar '13

-1 on breaking the existing Monoid instance. I'd prefer either: a) A newtype for the additional Monoid instance, or b) providing an associative operator equivalent to the new Monoid instance I'm not convinced that the replacement instance is more useful, let alone useful enough to break everything depending on containers. A lot of packages both on and off Hackage depend on Edward's code, almost all of which would break as a result of this change.

3 2

Haskell Platform 2013.2 Kick-Off
by Mark Lentczner 10 Mar '13

10 Mar '13

*All: * It's Haskell Platform season again! Here's the time line the 2013.2 release: - *Today* — Announce start of process, call for proposals for additions and changes - *March 25th* — Call for proposals ends (no more proposals considered) - *April 8th* — Proposals decided, Initial version list - *April 22th* — First candidates - *April 29th* — Open issues resolved, Second candidates - *May 6th* — Final release candidates *Library Maintainers:* Beginning of April I'll be e-mailing all library maintainers asking for the version to include in this release of HP. This is a good time to get what you want tested against 7.6.2 and up on Hackage. Even if the answer "the latest version, x.y.z" or "same as last time, x.y.z", I'd still like to hear from you with the version number when I e-mail. This time around I'll be trying to run cabal tests for packages if they exist. The state of proposals hasn't changed much since my message from Feb. 9th, (see copy below). What is needed ASAP is: - *hashable* - we need a proposal for this - someone? - *OpenGL *&* GLUT* - I understand from Jason that he's agreed to do the module re-work the group asked for. We don't need a proposal, but I'd like to hear from Jason how's it goin'. I'd still like to see proposals for *unordered-containers*, and *asson*, but not essential. *Distro packagers:* I'll be improving the scripts some this round. I'm looking to a) incorporate tests from packages that have them, b) considering building GHC from source rather than using the built distribution (for Mac OS X). Let me know what you need from the scripts. — Mark "Chief Haskell Gift-Wrapper" Lentczner Proposal details, from Feb. 9th e-mail: Proposals in flight for 2013.2: - *case-insensitive:* looking good - will require *hashable* - *attoparsec: *looking good - *JuicyPixels:* people like the idea of having a library like this one, perhaps even this one, but there is concern that this API hasn't baked enough. - *OpenGL *&* GLUT:* there is a proposal to remove these. The HP versions are very stale, and the new versions would require inclusion of packages* ObjectName*, *StateVar* and *Tensor* which has not met with approval. I would like to see those three packages removed, the modules folded back into OpenGL, and put under Graphics.Rendering.OpenGL. Proposals we need for 2013.2: - *hashable:* required by case-insensitive, no proposal yet Proposals I'd like to see for 2013.2: - *unordered-containers: *though, perhaps Johan is going to meld that into*containers*? I'd like to see the development plan for this (and * hashable*) settled. - *aeson:* we need this in the platform, as JSON has become ubiquitous. It requires settling *hashable* and *unordered-containers*. Proposals that will take some more thought, hence not likely for 2013.2: - *test-framework* & friends: these require a number of other packages like *ansi-terminal* and *hostname*. I suspect they should all just go in, but it will take some time to review and prep all that. - *criterion* & *statistics:* both require a number of smaller packages we don't have like*erf* and *math-functions*. Again, will take time to sort out. Areas still looking for good candidates (if these are simple could make it this round): - simple db like dbm or sqlite support - file utils for common file system manipulations - logging - 2D graphics - perhaps gloss and/or diagrams?

1 0

ANNOUNCE: hF2-0.2
by Marcel Fourné 09 Mar '13

09 Mar '13

Hi, this is the second release of hF2, a F(2^e) backend for cryptographic code, to be found at http://hackage.haskell.org/package/hF2 (or simply by "cabal install hF2") This library is used in hecc for elliptic cryptography on binary field curves and came into existence during my master thesis. Since the code from back then some speedups and changes to data representation were made which lead to an increase in speed from the first correct protoype to this release by the factor 10^86 on my main development machine. Sadly, this is still slower than pure C or Assembler versions, but a lot more portable, (arguably) easier to read and easier to parallelize. The code does automatic bit slicing and uses mainly the vector library as a fast backend. Feats of this release: - Speed (256 bit curve point multiplication in hecc is now at about a second in time) - LINEAR speedup in threaded execution with the number of cores (up to the number of bits divided by the wordsize) - Manually tested - Prelude-like Interface (more in progress) - Mostly timing attack resistant (also in progress) Next up: Testing and fixing hecc for this release. Have a nice weekend, Marcel -- Marcel Fourné OpenPGP-Key-ID: 4991 8AA4 202F 12AC 41F7 6C77 CA83 BDF0 7454 5C72 I am a programmer. I want languages and libraries, not just huge tools.

1 0

How to avoid trailing whitespace generated by Text.PrettyPrint.HughesPJ?
by Peter Simons 09 Mar '13

09 Mar '13

Hi guys, it seems to me like the HughesPJ pretty printer has trouble dealing with empty lines in a nested environment. Consider the following example: > import Text.PrettyPrint.HughesPJ > test1 = putStrLn $ render $ nest 4 $ vcat $ map text [ "line 1", "", "line 2" ] The 'test1' function prints the following output, where blanks have been replaced by underscores to make them visible: *Main> test1 ____line_1 ____ ____line_2 Now, I would like to avoid this kind of trailing whitespace in the document I'm generated -- but how? My first thought was to replace text "" by empty, but that change effectively removes the empty line altogether: > test2 = putStrLn $ render $ nest 4 $ vcat $ [ text "line 1", empty , text "line 2" ] *Main> test2 ____line_1 ____line_2 Is there another way to accomplish what I want? Take care, Peter

3 3

Taking over maintenance for the NetSNMP library
by Pavlo Kerestey 08 Mar '13

08 Mar '13

Hi, we want to publish a chage to the NetSNMP library that would introduce a more ressource friendly snmpBulkWalk binding. We have contacted the current maintainer with the patch but did not get any answer since one week. The library was last updated in 2009, last compiled with ghc 7.0, and looks like it is abandoned. The function in question would be: snmpBulkWalk :: Hostname -> Community -> OID -> IO (Either String [SnmpResult]) The rest of the library would stay the same for now. After consulting #haskell and #hackage irc channels we've got a suggestion to take over the package and bump the version to 0.2.* so that if the original developer wants to pick it up later, we can do a merge or fix the bugs in the current 0.1.* branch without breaking anyone's code. We would wait for another week with this and if there are no objections, then we will do as suggested. We would like to publish the library on github as well, so that its becomes easier for the others to help. Greetings, Pavel. -- Pavlo Kerestey Software Engineer at Global Access Internet Services GmbH https://kerestey.net | http://www.global.de

1 0

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