- Libraries - Haskell.org

how to contact me (sorry)
by Isaac Jones 08 Jan '06

08 Jan '06

Sorry for sending this to the whole list, but I correspond with a lot of you, so I thought I should mention what's up. In case anyone has been trying to contact me, I thought I'd mention that my syntaxpolice email has been down for a while now, though it will be coming back up soon. In the meantime, please contact me at ijones(a)debian.org :) peace, isaac

1 0

Re: Left-bias and non-structural equality.
by Okasaki, C. DR EECS 06 Jan '06

06 Jan '06

I've been having this argument with people for close to 10 years now. There are two similar but separate notions: equality and equivalence, where equality means "equivalent in all contexts" and equivalence means "equal in some contexts but not necessarily in others". (I'll leave it to others to give the base case of this recursive definition. :-) The problem is that Haskell has only a single Eq class, and it seems safe to assume that that is not going to change anytime soon. So which should it be, equality or equivalence? Many people want it to be equality, for reasons of mathematical purity, while many others want it to be equivalence, because it is so bloody useful. As I see it, if you are going to restrict yourself to only one of the two, equivalence is the better choice. Why? Because code designed to work with equivalence will still work if you happen to give it an equality relation, but code designed to work with equality can break if you happen to give it an equivalence relation. Another issue is that many *many* data structures can inherently only provide equivalence. The essential difference between equality and equivalence has to do with being able to substitute "equals for equals". For most data structures that have internal invariants, you can freely substitute equals for equals *outside* the abstraction boundary, but not *inside* the abstraction boundary. For example, you can't replace the left subtree of a balance binary search tree with another subtree with the same elements but a different shape, and expect the whole tree to still be balanced. The only way around this problem is to have an extra "wrapper" type and explicitly wrap/unwrap your data every time it crosses the abstraction boundary. The way I dealt with this in Edison was to provide two versions of many operations, such as insert and insertWith, where insert is designed with equality in mind and insertWith is designed with equivalence in mind. I have some sympathy for the argument that this pollutes the API, but in a way that is easy to understand if you understand the equality/equivalence issue. You might think that assuming equality will simplify the API, but your users would still need to understand the equality/equivalence issue or they are going to accidentally give you equivalence relations. -- Chris

1 0

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 04 Jan '06

04 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

Cabal and Hooks?
by Dimitry Golubovsky 04 Jan '06

04 Jan '06

I am developing an extension to HSFFIG to create Haskell packages out of C header files. Before I start reinwenting the wheel, I would like to reuse as much of Cabal functionality as possible. I am trying to figure out whether the following can be done with user hooks using Distribution.Smple. 1. I need to extend the Setup command line syntax with custom options (esp. Setup configure). For example, I need to specify locations for the imported C headers and libraries they relate to. The package description file does not seem to be a good place for them because on different systems these locations may be totally arbitrary. Results of parsing of those options must be visible to subsequent package building phases. These options also must appear in the help message. 2. I need to override the build process completely. The package build process is pretty much straightforward [1], but differs from the "standard" ghc --make: module dependencies are pregenerated by running GHC -M; all source files are compiled with the split_objs option one by one (when compiling tens/hundreds of modules with --make, memory used by GHC exceeds reasonable limits). Does the buildHook do the job (looks like it does, but just to make sure...)? 2a Another problem with build/install is that while the names of exposed-modules are known in advance (basically there is only one module to expose which re-exports the rest), names of other-modules are only known after the build completes. The source splitter may leave tens or even hundreds of separate modules (see HSFFIG tutorial: for example, a single module is created for every structure/union). It is impossible to specify them all in the package description file. Provided that the location of those modules is known, is there any way to state in the package description file that all modules at the given location should be "other-modules" (kind of a regexp)? I see the possibility to use Distribution.Make as a last resort. However it delegates too much functionality to the make and configure utilities; I would be happy to have more Cabal on my side ;) Thanks for any ideas. --------------- [1] http://haskell.org/hawiki/HsffigLinkageOptimization -- Dimitry Golubovsky Anywhere on the Web

1 0

Data.Set clone available
by Adrian Hey 01 Jan '06

01 Jan '06

Hello folks, I've put and AVL tree based clone of Data.Set here.. http://homepages.nildram.co.uk/~ahey/HLibs/AvlSet/AvlSet.html This should make it easy to do comparitive test/measurements between the two and maybe experiment with any wishlist extensions you want for the revised API (which is WIP I believe), using the underlying AVL implementation. I'll do the same thing for Data.Map soon, though it'll probably have to wait until next weekend now. This module is completely untested but the underlying AVL library has been pretty thouroughly tested. So it should work OK. If you use it and find any problems please let me know. Regards -- Adrian Hey

1 0

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

30 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 23 Dec '05

23 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