June 2010 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

[darcs patch] filepath: normalise trailing dot
by Conrad Parker 21 Dec '10

21 Dec '10

Hi, the attached darcs patch modifies the behaviour of normalise to handle trailing dots in a path. The previous behaviour yielded this: Prelude System.FilePath> normalise "../." "../." Prelude System.FilePath> normalise ".././" ".././" Prelude System.FilePath> normalise ".././.." "../.." This patch modifies dropDots such that the check for (".":[]) only occurs once for the path, after which a driver function dropDots' is used which skips this check. Hence "." can be removed from the end of a longer path, but a path of just "." is unchanged. (my trac account is pending verification, I'll reply with a trac ticket # later if needed) cheers, Conrad.

4 7

xhtml maintainership?
by Ganesh Sittampalam 03 Aug '10

03 Aug '10

Hi, I believe the xhtml package is currently unmaintained. As it is something that used to be distributed with GHC, is it something that libraries@ could/should take on? Cheers, Ganesh

6 10

Proposal: Make Permissions type abstract
by Ian Lynagh 03 Aug '10

03 Aug '10

Hi all, Proposal: Make Permissions type abstract Ticket: http://hackage.haskell.org/trac/ghc/ticket/4149 The Permissions type in System.Directory aims to be a lowest-common-denominator type. This makes it unsuitable for some tasks. For example, a copyPermissions primitive had to be implemented, as it is not possible to use the getPermissions and setPermissions functions to copy the permissions from one file to another: $ ls -l foo* -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo1 ---------- 1 ian ian 0 Jun 23 21:27 foo2 ---------- 1 ian ian 0 Jun 23 21:27 foo3 $ hd -e 'System.Directory.copyPermissions "foo1" "foo2"' $ hd -e 'System.Directory.getPermissions "foo1" >>= System.Directory.setPermissions "foo3"' $ ls -l foo* -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo1 -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo2 -rwx------ 1 ian ian 0 Jun 23 21:27 foo3 I think we would be better served by the Permissions type being abstract in System.Directory, with the unix and Win32 packages providing the real definition, and some system-specific functions on it. This would allow the generic get/set functions to implement copyPermissions. This proposal just does the step which has most potential to cause problems for packages that use the type: It makes the type abstract in System.Directory (and adds explicit setter functions, so no functionality is lost). (patch is in the ticket) The type is also exported in Haskell 98's Directory module. I think this should get its own copy of the type. Suggested discussion deadline: 9 July 2010. Thanks Ian

3 3

Corrected unix patch
by Eric Mertens 14 Jul '10

14 Jul '10

Hello, It looks like my darcs-fu is a bit rusty. I've attached the patch with all of the changes to this message for adding the missing functions to unix package Sorry for confusion. -- Eric Mertens <emertens(a)galois.com> Galois, Inc.

4 4

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

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