- Libraries - Haskell.org

ANNOUNCE: fgl-5.4.2.3
by Ivan Lazar Miljenovic 12 Jul '10

12 Jul '10

I'm pleased to present the first new release of fgl [1] since Thomas Bereknyei took over maintaining it from Martin Erwig. [1] http://hackage.haskell.org/package/fgl Before people start panicking, rioting, etc., please check the version number: this is just a bug-fix release, and not the complete re-write version which we've been talking about (since we got a little sidetracked, etc.). As such, the API hasn't changed, and this should fit right in to packages already using fgl (sorry to all those people who followed my advice and put "fgl == 5.4.2.2" in the build-depends fields of their packages' .cabal files, but I didn't expect to make another 5.4.y release). The exact change that has been made is to fix a bug pointed out to me by Tristan Allwood, in that Data.Graph.Inductive.PatriciaTree didn't support multiple edges (and furthermore this wasn't specified in the documentation). This has now been rectified. As an indication of what these changes mean, see this sample call graph produced by my SourceGraph program; when using PatriciaTree from fgl-5.4.2.2 the lines were all the same thickness; now there is among other things a loop of width 32 on getExp and a line of width 7 from getExp to maybeEnt. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 1

darcs patch: Correct documentation of readProcess
by Simon Hengel 11 Jul '10

11 Jul '10

1 patch for repository http://darcs.haskell.org/packages/process: Sun Jul 11 09:55:17 CEST 2010 Simon Hengel <simon.hengel(a)wiktory.org> * Correct documentation of readProcess * The return type is not 'Either (ExitCode, String) String', it is just 'String' * readProcess does not return stderr + stdout, it returns just stdout

2 1

darcs patch: Remove duplicated word in documentation
by Simon Hengel 11 Jul '10

11 Jul '10

1 patch for repository http://darcs.haskell.org/packages/base: Sun Jul 11 09:27:03 CEST 2010 Simon Hengel <simon.hengel(a)wiktory.org> * Remove duplicated word in documentation

2 1

Containers and strictness continued
by Milan Straka 09 Jul '10

09 Jul '10

Hi all, for my work on the containers I need to settle some questions about strictness. Thank you very much for your opinions. Discussion ends: 23. July 2010. 1) Strictness of keys and values in the datatype. Currently we have the following strictness flags in the datatypes: - IntMap: !key value - IntSet: !key - Map: !key value - Set: key I vote for changing Set to store keys also strict. Storing values as nonstrict probably makes sense. 2) Strictness of keys and values in the method definitions. The IntMap.lookup (lookup k t = ... seq k ...) evaluates the given key even if it is not needed (when searching empty tree). Some methods are more carefull. I vote for all IntMap, IntSet, Map and Set methods that are given a key value (insert, delete, member, ...) to be strict in the keys. This a) would be consistent with 1) b) would be a bit more efficient (~5% in the IntMap.lookup case) 3) Strict folds Currently there are no strict folds. I vote for adding strict folds (fold', foldWithKey' when appropriate) to all Map, Set, IntMap, IntSet. Cheers, Milan Straka PS: I will be unavailable and not reading mail till 19. July 2010.

7 10

Proposal: Add these two handy functions to Data.List
by Cale Gibbard 08 Jul '10

08 Jul '10

When working with the list monad, I often find myself in need of one of the two following functions: -- | Produce a list of all ways of selecting an element from a list, each along with the remaining elements in the list. -- e.g. select [1,2,3,4] == [(1,[2,3,4]),(2,[1,3,4]),(3,[1,2,4]),(4,[1,2,3])] -- This is useful for selection without replacement in the list monad or list comprehensions. select :: [a] -> [(a,[a])] select [] = [] select (x:xs) = (x,xs) : [(y,x:ys) | (y,ys) <- select xs] -- | Produce a list of all ways of separating a list into an initial segment, a single element, and a final segment. -- e.g. separate [1,2,3,4] == [([],1,[2,3,4]),([1],2,[3,4]),([1,2],3,[4]),([1,2,3],4,[])] separate :: [a] -> [([a],a,[a])] separate [] = [] separate (x:xs) = ([],x,xs) : [(x:us,v,vs) | (us,v,vs) <- separate xs] It would be really nice if they were in Data.List. The first I find occurring in my code moreso than the second, though just a moment ago, the second of these was quite useful to a beginner on #haskell, and it has come up quite a number of times before for me. Twan van Laarhoven suggested that the following generalisation of select might also be useful: select' :: [t] -> [(t, ([t] -> [t]) -> [t])] select' [] = [] select' (x:xs) = (x,\f -> f xs) : [(y,\f -> x:ys f) | (y,ys) <- select' xs] This satisfies the equation select = map (second ($ id)) . select' and allows for simple replacement after modification of the selected element, for instance: [xs (toUpper x :) | (x,xs) <- select' "abcd"] == ["Abcd","aBcd","abCd","abcD"] but we're unsure if this might be too subtle to be as useful on a regular basis. - Cale Gibbard

9 11

DRBG pre-announce and a discussion on RNG/Crypto infrastructure
by Thomas DuBuisson 04 Jul '10

04 Jul '10

The DRBG package [1] is a partial implementation of NIST SP 800-90 section 10, specifically the hash and HMAC based cryptographically secure random number generators are implemented. Before doing further work I feel the state of affairs of cryptography on hackage needs to change. As has became too common, DRBG implements (or should implement) several features that could be done once for all time in a quality Crypto package. Features such as type classes for hashes and ciphers, an hmac definition, and a MonadRandom or something similar for random number generators that can fail. What existing code implements one or more of these features that should be able to use a central Crypto package? Happstack, SHA2, DRBG, SHA, hS3 (actually uses crypto despite [Word8] where ByteString should be used), hoauth, and a few partial-bindings to OpenSSL satisfy several needs. Future Crypto Library Principles I propose two "new" libraries be built and receive some higher level of community attention. One is "Crypto" which will define type classes and a limited set of common generic algorithms (ex: HMAC, cipher modes of operation). The other is "crypto-algs" which implements (and instantiates type classes for) as many common algorithms as we can reasonably group together with similar interfaces. I feel the breakdown is important - if the community-accepted interface is separated from any algorithms then maintainers of alternate implementations are more likely to accept the interface. Enumerating principles I support: * Lazy ByteStrings should be used for all input data * While "over-typeclassification" should be avoided, two or three basic classes of "Digest", "Cipher", and "CryptoRandom" make good sense. * CryptoRandom, and related infrastructure would closely follow Random and MonadRandom except for allowing clean failure. * Digest result types should be unique to the digest (a la pureMD5, contrary to SHAs use of "Digest" for 4 different hashs and contrary to SHA2s use of ByteString for all digests) * For Crypto-Algs pure Haskell code may be preferred but should not be used when costing over ~20% performance degradation when compared to other available implementations. * No dependence on external libraries (e.g. no OpenSSL bindings) * Keys should receive their own data type declarations (no cryptographic information floating around in a naked ByteString) * Data types should have Binary and Serialize instances. * All code should be licensed BSD3 or equivalent Open Questions on Class Design What should be made instances of our classes. Should an empty data declaration have an instance, and the class have a way to "extract" the actual digest [2]? Perhaps it should be the data type containing the digest that is the instance, so the hash algorithm can be inferred based on the result type. Required methods: I'd propose we follow [3] (see [2] for instances) except removing the empty data declarations, using the digest/key types for the instance. In brief, this includes encrypt/decrypt (or 'hash), strength, outputLength, blockLength, What algorithms are generic enough to include in Crypto? I'd say anything that works for all instances of {Cipher, Digest}. Minimum quality for inclusion: A suite of KATs and some straight forward QuickCheck tests. Anticipating Concerns 1) (Re-) Implementing Crypto is hard / dangerous / a waste of time Most the benefit I aim for is in the common interface, not the algorithms. That said, the -Algs package can largely be a gathering of best-of-hackage with sanitized interface and continually-updated as higher-performance implementations come available. This might have been how the current "Crypto" package started, I don't know, but it is no longer in a sane or useful state. 2) OpenSSL is fine For some people, yes - absolutely. Not just fine but insane to replace, seeing as it's (partly) FIPS certified. For other people, such as basically all the packages I listed above, it's obviously lacking something be it portability, footprint, or interface. 3) The Monad class / MonadRandom can fail - it's called "error" and "fail". This is a matter of taste. I personally wish Haskell didn't have exceptions or had an explicitly exceptionless type. At any rate, the random work would probably come last, especially if I'm doing the implementation. I intend to tackle this once I get some personal time freed up (around mid June). If you're interested then please feel free to lay claim to some part of this problem or comment on the proposal. Cheers, Thomas [1] http://code.haskell.org/~tommd/DRBG/ Remaining tasks include optimization, test suite (NIST provides a large body of KATs), self test procedures, and the higher level interface (section 9). [2] http://code.haskell.org/~tommd/DRBG/Test/KAT.hs [3] http://code.haskell.org/~tommd/DRBG/Data/Crypto/Classes.hs

6 9

#4159: move Monad and MonadFix instances for Either from mtl to base
by Ross Paterson 01 Jul '10

01 Jul '10

The proposal is to move the Monad and MonadFix instances for Either (currently in the mtl package) to Control.Monad.Instances and Control.Monad.Fix respectively (both in the base package). The Monad instance is still an orphan, to retain Haskell 98 compatibility, but the MonadFix instance is together with its class. The Error constraint is removed from both instances, and the default definition of fail is used. Discussion deadline: 20th July 2010

16 44

Re: [Haskell-cafe] State of the Hackage: Q1, Q2 2010
by Don Stewart 01 Jul '10

01 Jul '10

I think we need to standardise the presentation of this data, and provide a lib to access it. I'll think some more about it. Should be possible to automate it all now (that's mostly done), publish in a known location, and provide an API for queries. inforichland: > If anyone wants to see the popularity of their particular package(s), dons has > kindly left a .txt file with the information > at the following URL: http://code.haskell.org/~dons/hackage/Jun-2010/ > popular.txt . > > Of course, this being Haskell, I had to whip up a little script to get the > information for you. > > It may not be the most elegant, but it only took a few minutes and it does the > job. You'll find it attached :) > > Cheers, > - Tim > > On Wed, Jun 30, 2010 at 5:08 PM, Don Stewart <dons(a)galois.com> wrote: > > > Downloads and popular packages on Hackage for Q1 and Q2 this year. > > http://donsbot.wordpress.com/2010/06/30/ > popular-haskell-packages-q2-2010-report/ > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 1

Containers and strictness
by Milan Straka 01 Jul '10

01 Jul '10

Hi, I am working on improving containers performance and have written a draft paper about it http://fox.ucw.cz/papers/containers/containers.pdf I wanted to start a new thread in response to strictness issues brought up by Claus Reinke. > - IntMap and Map expose different APIs wrt strictness > http://www.haskell.org/pipermail/libraries/2009-March/011399.html > http://www.mail-archive.com/haskell-cafe@haskell.org/msg48925.html > > - to work around the non-strict Map fold, users have to > resort to nested folds (non-strict fold to convert to list, > then strict foldl' over list) and other tricks: > http://www.haskell.org/pipermail/haskell-cafe/2010-June/079098.html > > similarly non-trivial thinking is required to work around other > no-control-over-strictness issues in the APIs, bypassing the obvious > functions and using non-obvious ones based on > knowledge about their implementation > > - strictness is used inconsistently: > http://hackage.haskell.org/trac/ghc/ticket/4109 > > - strictness is not documented: !!! > search for "strict" in the Data.Map/IntMap documentation.. > > this is really bad - the only way for users to become aware > of strictness problems is by running into them, and the only way to fix > strictness-related performance issues is by referring > to the implementation (in theory, an implementation change > could invalidate lots of performance fixes in production code) I need some opinion: - Do you think methods like insert/lookup/delete/etc should be strict in key/element? As Claus wrote, right now it is undocumented and inconsistent (both in the methods of one container and also in the same methods of different container). The problem is the following: a lookup on an empty container does not really have to evaluate the key. Should we honour it or should we sacrifice it to be faster and consistent with other methods (eg., insert has to be strict in the key). - The Set/Map, IntSet/IntMap do not currently have a strict fold. Do you think it should be added to the API? Cheers, Milan

8 18

dirs in Emacs/Vim in Cabal
by Chris BROWN 01 Jul '10

01 Jul '10

Dear Haskellers, I am in the process of creating a cabal HaRe and I have run into a minor problem. I have an emacs and a vim script that HaRe uses to invoke the refactorer from the two editors. In those scripts, I point HaRe to a directory containing some libraries it needs to chase the imports of the modules. Cabal installs these libraries as data files into whatever prefix the user requests at install time. However, the problem I have is that it then requires a manual user intervention to manually configure emacs/vim to point to this new directory in the 'customizable' panel of HaRe. My question is: Is it possible to allow the emacs/vim scripts that I have know where this directory is automatically? I hope someone can help, Kindest regards, Chris Brown.

2 1