December 2005 - Libraries

external core
by John Meacham 22 Mar '06

22 Mar '06

Now, the external core feature of ghc is great, but it is not utilized very much. The main reason I think is that there is a large barrier to entry in writing something that uses it since you need to parse/generate it. It would be nice if there were a standard library that came with ghc (or cabalized and portable even better) that could parse and pretty print external core. ideally, one could write a simple pass-through core processor that interacts with ghc in a single line and someone working on a new optimization need only worry about that. Also, it would make it very easy for jhc to generate and parse ghc core files (always an ulterior motive). I wanted to use jhcs front end to generate ghc core so I could get a true measure of the difference in just their back-end performance without taking into account ghc's superior high-level optimizations. In any case. I think all the code is out there in ghc and it just needs to be separated and cabalized. I know there was talk of creating a ghc internals library, but it would be nice if this code were portable and independent. John -- John Meacham - ⑆repetae.net⑆john⑈

3 4

Trie implementation
by Keith Wansbrough 10 Mar '06

10 Mar '06

Hi... I was writing some code yesterday to walk over a directory tree, and needed a Trie. Not seeing one around, I wrote a basic implementation of the functions I needed (attached below). Has anyone else done this? Should I polish it up and offer it for inclusion in Data? --KW 8-)

7 8

simplifying user hooks (non-backward-compatible)
by Isaac Jones 16 Jan '06

16 Jan '06

Andres Loeh proposed simplifying the hooks interface now that they've grown to include not only pre-and-post hooks, but also er, "during" hooks too. That is, all of the actions are hooks now (preConf, confHooks, postConf). http://hackage.haskell.org/cgi-bin/trac/trac.cgi/ticket/23 So we could now get rid of the pre and post hooks, as long as the user could call to the default hooks thusly: myHooks = defaultUserHooks { confHook = myConf } myConf pd cf = do myPreConf lbi <- confHook defaultUserHooks myPostConf pd cf lbi (for suitable myPreConf and myPostConf functions) This would greatly simplify the Distribution.Simple.UserHooks structure bringing it from 34 fields to 14 fields, or so. Downsides: Making pre and post hooks would now be slightly harder, and it would break existing hooks-using code. I like it. What are your feelings? peace, isaac

2 6

Data.Version.parseVersion
by Einar Karttunen 04 Jan '06

04 Jan '06

Hello What is the correct way to use Data.Version.parseVersion? It seems to start with the "wrong" result and the last one is the intended one. e.g. "1.2.3" is parsed as: [(Version {versionBranch = [1], versionTags = []},".2.3"), (Version {versionBranch = [1,2], versionTags = []},".3"), (Version {versionBranch = [1,2,3], versionTags = []},"")] This is different from the usual read instances. Is the behaviour intended? Should I just use that as: filter (null . snd) $ readP_to_S parseVersion "1.2.3" :: [(Version,String)] - Einar Karttunen

2 1

Re: [Haskell-cafe] strange stack overflow with Data.Map
by David Roundy 03 Jan '06

03 Jan '06

On Thu, Dec 29, 2005 at 01:42:29PM +0100, Christian Maeder wrote: > David Roundy wrote: > >>stats elems = foldl add_elem Map.empty elems > >>add_elem m x = Map.insertWith (+) x 1 m > > > >>main = print $ stats $ take 1000000 $ repeat 1 > > > >This program has a space leak and runs out of stack space. I'm guessing > >that I'm being bit here by an unnatural amount of laziness in > >Map.insertWith, but I can't see how to fix this. :( I'm sure it's > >something elementary... > > try: > > stats = foldl' add_elem Map.empty > add_elem m x = myinsertWith (+) x 1 m > > myinsertWith f k v m = > case Map.lookup k m of > Nothing -> Map.insert k v m > Just w -> let r = f v w in r `seq` Map.insert k r m Thanks, that does it! I had tried something like that, but without the foldl', and had tried foldl', but without the myinsertWith. The reason I didn't spend much time using this implementation is that for large maps, it will take twice as long as Map.insertWith, so I assumed (incorrectly) that Map.insertWith should be written so that it behaves in a non-leaky manner. Should the Map modules have an additional Map.insertWith' that behaves strictly, or might it be the case that you always want strict behavior when using insertWith? -- David Roundy http://www.darcs.net

9 19

Re: [Haskell] more newbie questions regarding do syntax, mondic context & Data.HashTable
by Jean-Philippe Bernardy 29 Dec '05

29 Dec '05

On 12/29/05, Hunter Kelly <retnuh(a)gmail.com> wrote: > Hi there, I'm having some trouble trying to get information out > of a HashTable. > > I'm using it to represent a set (I'm using a hash table for O(1) > speed reasons to compare against Data.Sets O(lgN) operations). > I don't think anyone has ever asked for a "pure" version of the hashtable. (It could be frozen and thawed in the same fashion as Arrays are). Maybe someone has written something like that and is willing to share? On the other hand, it's entirely possible that you can get away with either Data.Map or saying within the IO monad. Cheers, JP.

2 1

RE: cabal release (was: cabal experiences)
by Simon Peyton-Jones 27 Dec '05

27 Dec '05

| then. 1.2 might be a good version to get into ghc 6.6, though I | expect that it won't have configurations or shipments, since we won't | have much time to try those out. What's the schedule like for ghc 6.6? Well, the plan is for 6.6 to have impredicative types, and revised GADTs. I'd like to fix the interaction of type classes and GADTs too. And we'd like to have shaken down the parallel implementation a bit. The natural time for 6.6 feels like at least 3 months from now -- and we'd rather not get pinned down to any dates for a while yet. If the reason you want 6.6 is to get a new Cabal, why not download a new Cabal package? Or is there another reason you want 6.6? Bug-fixes to 6.4 are a much smaller deal. Simon

9 9

release of sha256/sha512 library
by David Mercer 27 Dec '05

27 Dec '05

We are pleased to announce Version 0.21a, the initial functioning release of Shaskell, our SHA2 library for (so far) ghc6. It supports sha256 and sha512 hashes in this version, and is "pure": no monads or C libraries are involved! Source and Ubuntu 5.04 binaries are at: http://davidmercer.nfshost.com/projects/shaskell/ (Shaskell-0.21a.hs is the current release). Project homepage is at: http://davidmercer.nfshost.com/projects/shaskell/shaskell.html Future releases will additionally support sha224, sha384, be Cabal-ized, and supply wrappers for hashing files and other data sources where the message length is not known in advance. Special thanks to Dominic Steinitz for invaluable suggestions. Any testing or feedback is of course welcome and appreciated! It is released under the (BSD compatible) MIT X license. Happy New Year, hopefully this will help improve the security of future crypto systems written in Haskell. Cheers, -David Mercer Tucson, AZ

1 0

RE: lawbreakers in Text.PrettyPrint.HughesPJ
by Simon Peyton-Jones 22 Dec '05

22 Dec '05

I had trouble parsing your message. Are you saying that (a) before changing the library you have a program that compiles ok (b) after changing the library, the program becomes gigantic and won't link ? Nothing to do with *running* the program? If I have understood right, what are the sizes of the .o files in (a) and (b)? Has one (or lots) gotten gigantic? Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Christian | Maeder | Sent: 30 November 2005 14:45 | To: Simon Peyton-Jones | Cc: libraries(a)haskell.org | Subject: Re: lawbreakers in Text.PrettyPrint.HughesPJ | | Christian Maeder wrote: | > I've tried both versions, without noticing a difference. So take the | > following patch (as suggested by Conal). | | I became a problem with my (Conal's) suggested patch on a mac. When | compiled with optimization the code was so blown up that it could no | longer be linked on a mac. (The problem does not occur if only isEmpty | is changed as suggested before.) | | Unfortunately the example is large and takes ages to be reproduced and | it took me an age to find that the cause was my change to our version of | HughesPJ.hs. | | Christian | | the link error shows up as: | | [...] | /usr/bin/ld: ./Logic/Logic.o relocation overflow for relocation entry | 5401 in se | ction (__TEXT,__text) (displacement too large) | collect2: ld returned 1 exit status | make: *** [hets] Error 1 | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 2

official Cabal / Hackage wiki
by Isaac Jones 15 Dec '05

15 Dec '05

The new Cabal / Hackage wiki and bug tracking system is at: http://hackage.haskell.org/trac/hackage [1] Please report any Cabal (or HackageDB, cabal-get, etc) bugs there with "new ticket". Trac is pretty neat, you can inter-like wiki pages and tickets, as well as source code. Please feel free to start editing pages and adding information about Cabal. peace, isaac [1] Why the hackage...hackage redundancy? Well I'm basically hoping to roll out the "hackage" server as a community development site. As such, we have http://hackage.haskell.org/trac/ghc as well :)

1 0