September 2010 - Libraries

Re: [Haskell-cafe] Re: Crypto-API is stabilizing
by Sebastian Fischer 05 Sep '10

05 Sep '10

On Aug 27, 2010, at 11:12 AM, Heinrich Apfelmus wrote: > Is it actually necessary to use a type class here? The situation is > very similar to > > Luke Palmer. Haskell Antipattern: Existential Typeclass. > http://lukepalmer.wordpress.com/2010/01/24/ > > I suggest to use good old data types > > data Key = Key { > encrypt :: B.ByteString -> B.ByteString, > decrypt :: B.ByteString -> B.ByteString, > keyLength :: BitLength, > serialize :: B.ByteString} > > rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g) In general, I like this approach, but what are encrypt privateKey or decrypt publicKey supposed to do? A type-class solution also does not *prevent* programmers to perform such non-sensical calls, but the data-type solution *forces* programmers to provide non-sensical encrypt and decrypt functions when creating the public and private keys. >>>> class (Binary p, Serialize p) => AsymCipher p where >>>> generateKeypair :: RandomGen g => g -> BitLength -> Maybe >>>> ((p,p),g) >>>> encryptAsym :: p -> B.ByteString -> B.ByteString >>>> decryptAsym :: p -> B.ByteString -> B.ByteString >>>> asymKeyLength :: p -> BitLength Why not use generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p)) where MonadRandom is from [1]. Sebastian [1]: http://hackage.haskell.org/package/MonadRandom -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

4 10

Proposal: Performance improvements for Data.Set
by Johan Tibell 04 Sep '10

04 Sep '10

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4280 Proposal: Performance improvements for Data.Set Following on from ticket #4277 here is a similar patch for Data.Set. This proposal provides a patch that improves performance for many parts of the API. Three standard techniques are applied to the code: * Worker/Wrapper transformations of recursive functions with constant arguments (aka. the static argument transformation). * Explicit inlining of wrapper functions. * Explicit strictness of keys to functions. Three complementary, but orthogonal patches are provided. * Add a testsuite, with coverage data (currently 51% of top level functions, and all core functions). * Add a micro-benchmark suite based on Criterion, for empirical evidence of improvements to each function. * The optimization patch itself. All 3 patches should be applied, under this proposal. The benchmark results are relatively clear: 32% faster on OS X 10.5.8 on 2 GHz Core 2 Duo The consideration period is 3 weeks (before ICFP). Work carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell and Don Stewart.

3 3

Installation question: cpphs, unix, and HEAD
by Kathleen Fisher 04 Sep '10

04 Sep '10

I am trying to install the cpphs package with the current HEAD version of Haskell. When I ask cabal to do the installation, I get the following error: > Babylon:/Users/kfisher/sw/ghc-head-libraries/cpphs-1.11> ~/.cabal/bin/cabal install cpphs -w ~/ghc-head/bin/ghc --with-haddock=/Users/kfisher/ghc-head/bin/haddock --package-db=/Users/kfisher/ghc-head/lib/ghc-6.13.20100831/package.conf.d > Resolving dependencies... > cabal: cannot configure unix-2.4.0.1. It requires base ==4.2.* > For the dependency on base ==4.2.* there are these packages: base-4.2.0.0, > base-4.2.0.1 and base-4.2.0.2. However none of them are available. > base-4.2.0.0 was excluded because base-4.3.0.0 was selected instead > base-4.2.0.0 was excluded because of the top level dependency base -any > base-4.2.0.1 was excluded because base-4.3.0.0 was selected instead > base-4.2.0.1 was excluded because of the top level dependency base -any > base-4.2.0.2 was excluded because base-4.3.0.0 was selected instead > base-4.2.0.2 was excluded because of the top level dependency base -any > Babylon:/Users/kfisher/sw/ghc-head-libraries/cpphs-1.11> This seems odd for multiple reasons: 1. I already have unix-2.4.0.1 installed (it was a boot library). So why is cabal trying to install it again? 2. Given that I already have unix-2.4.0.1 installed and my base is 4.3.0.0, why does unix-2.4.0.1 report that it needs base==4.2.*? 3. Given that the cabal file for cpphs says it needs base < 6 and haskell98 and my package database satisfies both of those constraints, why is cabal trying to install anything else? I include the listing of my installed packages below. What is going on is probably obvious to someone who knows more about the library installation process. Any ideas? Kathleen > Babylon:/Users/kfisher/sw/ghc-head-libraries/cpphs-1.11>~/ghc-head/bin/ghc-pkg list > /Users/kfisher/ghc-head/lib/ghc-6.13.20100831/package.conf.d: > Cabal-1.9.2 > HUnit-1.2.2.1 > array-0.3.0.0 > base-4.3.0.0 > bin-package-db-0.0.0.0 > (binary-0.5.0.2) > bytestring-0.9.1.7 > containers-0.3.0.0 > directory-1.0.1.2 > dph-base-0.4.0 > (dph-par-0.4.0) > (dph-prim-interface-0.4.0) > (dph-prim-par-0.4.0) > (dph-prim-seq-0.4.0) > (dph-seq-0.4.0) > extensible-exceptions-0.1.1.2 > ffi-1.0 > filepath-1.2.0.0 > (ghc-6.13.20100831) > ghc-prim-0.2.0.0 > (haskell2010-1.0.0.0) > haskell98-1.0.1.1 > hpc-0.5.0.5 > integer-gmp-0.2.0.0 > mtl-1.1.0.2 > old-locale-1.0.0.2 > old-time-1.0.0.5 > pretty-1.0.1.1 > process-1.0.1.3 > random-1.0.0.2 > regex-base-0.93.2 > regex-posix-0.94.4 > rts-1.0 > syb-0.2.1 > template-haskell-2.4.0.0 > time-1.2.0.3 > unix-2.4.0.1

2 1

installing cpphs, unix, in HEAD
by Kathleen Fisher 04 Sep '10

04 Sep '10

BTW, when I did the installation process by hand, unpacking cpphs, compiling Setup, then doing configure, install, and build, everything worked fine. The same basic thing happened when I tried to install parsec-3.1.0. Cabal failed to install, reporting a problem with base dependencies. But installation by hand succeeded. Kathleen

1 0

Proposal: Add strict versions of foldlWithKey and insertLookupWithKey to Data.Map
by Johan Tibell 04 Sep '10

04 Sep '10

http://hackage.haskell.org/trac/ghc/ticket/4278 Proposal: Add strict versions of foldlWithKey and insertLookupWithKey to Data.Map This proposal depends on #4277 [1]. The current Data.Map API lacks two important functions: * A strict left (pre-order) fold -- needed to e.g. sum all the values in a map efficiently. * A strict insertLookupWithKey' -- needed to e.g. update an integer counter and retrieve the previous value in a single traversal. The benchmark we ran indicates that foldlWithKey' is 95% faster than its lazy counter part.insertLookupWithKey' is only 6% faster, but the speedup is highly dependent on how many times each element is update. Each element was only updated once in our benchmark so real speedups should be larger. The consideration period is 3 weeks. 1. http://hackage.haskell.org/trac/ghc/ticket/4277

4 5

mtl library in HEAD?
by Kathleen Fisher 03 Sep '10

03 Sep '10

I'm trying to install the mtl package with the current HEAD version of Haskell, and I get the following error message: > Control/Monad/Error.hs:76:10: > Duplicate instance declarations: > instance Error e => Monad (Either e) > -- Defined at Control/Monad/Error.hs:76:10-38 > instance Monad (Either e) -- Defined in Control.Monad.Instances > > Control/Monad/Error.hs:87:10: > Duplicate instance declarations: > instance Error e => MonadFix (Either e) > -- Defined at Control/Monad/Error.hs:87:10-41 > instance MonadFix (Either e) -- Defined in Control.Monad.Fix > cabal: Error: some packages failed to install: > mtl-1.1.0.2 failed during the building phase. The exception was: > ExitFailure 1 The library installs fine with earlier versions of Haskell. Is there something wrong with my installation, or is this a new incompatibility? If the latter, is a corrected version of the mtl library going to be available soon? Alternatively, how can I fix it? Kathleen

3 3