- Libraries - Haskell.org

transforming xhtml attributes
by Chris Dornan 11 May '12

11 May '12

Folks, I am proposing to extend the xhtml package slightly to better support attribute munging. Currently you would use (!) to add a bunch of attributes to an element, thus: b1 = button noHtml ! [name "go", value "go"] The problem, as pointed out by mistuke[1] is that there is no way to safely add attributes as this could result in an attribute being bound ambiguously and illegally [2] thus: b2 = b1 ! [value "oops"] Apparently this can lead Haddock to generate illegal (X)HTML [1]. My proposed solution is to add a new CHANGEATTRS class with the overloaded function: changeAttrs :: CHANGEATTRS a => a -> ([HtmlAttr] -> [HtmlAttr]) -> a and to export a function for analysing the (abstract) HtmlAttr type: htmlAttrPair :: HtmlAttr -> (String, String) CHANGEATTRS/changeAttrs/htmlAttrPair works just like ADDATTRS/(!) except that the attributes can be analysed and transformed. extend_name :: Html -> Html extend_name h = h `changeAttrs` map f where f a = case htmlAttrPair a of ("name",nm) -> name $ "foo_" ++ nm _ -> a Finally, I have an embarrassing confession to make -- I forgot that I should be getting the changes reviewed here -- even for such a modest widening of the API -- and have already put out 3000.2.1 with these additions onto Hackage! Comments and feedback welcome though, Chris [1] https://github.com/haskell/xhtml/issues/2 [2] http://www.w3.org/WAI/GL/WCAG20-TECHS/H94.html

1 0

Proposal: unify constant functors
by wren ng thornton 08 May '12

08 May '12

Hello all, I recently (re)noticed the following duplication: base:Control.Applicative newtype Const a b = Const { getConst :: a } instance Functor (Const m) where... instance Monoid m => Applicative (Const m) where... transformers:Data.Functor.Constant newtype Constant a b = Constant { getConstant :: a } instance Functor (Constant a) where... instance Foldable (Constant a) where... instance Traversable (Constant a) where... instance (Monoid a) => Applicative (Constant a) where... I don't see any reason for this redundancy. I propose we: (1) add the Foldable and Traversable instances to base, and (2) deprecate transformers:Data.Functor.Constant This will cause breakage to any orphan instances of Foldable/Traversable for Const, but that seems fine by me. Eventually we'll want to remove transformers:Data.Functor.Constant (or have it re-export the Const stuff from base:Control.Applicative); but that can be handled later. Deadline: 14 May 2012. -- Live well, ~wren

13 22

Proposal: To add 2 new lower-level concurrency constructs and rebuild Concurrent.Chan using them
by Ivan Tomac 08 May '12

08 May '12

Hi, I've recently noticed unGetChan and isEmptyChan have been deprecated as a result of these two bug reports: http://hackage.haskell.org/trac/ghc/ticket/3527 http://hackage.haskell.org/trac/ghc/ticket/4154 I was working on an alternative implementation of concurrent channels (concurrent streams) to use as a building block for FRP and thought while I'm at it I'd have a go at fixing the problem with concurrent channels. I've attached the files for a reimplementation of concurrent channels, 2 implementations of lower-level concurrent queues, one that only supports non-blocking reads, and another that supports both blocking and non-blocking reads, and an implementation of concurrent streams. The reimplementation of concurrent channels is built on top of the blocking queue. The streams are built on top of the non-blocking queue and have Functor and Applicative instances. The reimplementation of concurrent channels passes the two tests in the bug reports above. I haven't run further tests though. The logic for how the channel operations are supposed to proceed is summarized in Chan.hs. Due to an extra lock this implementation is likely a bit slower than the old implementation. One assumption that has been made is that IORef reads and writes are atomic. In other words that if there are two or more concurrent writes to the same IORef, one of them will successfully write its data to it. I have not been able to find exact semantics of IORefs though I've asked in #haskell and others have suggested that the assumption is valid. Proposal: 1) split concurrent channels from base into a separate library of higher level concurrency primitives 2) add concurrent queues to the library of higher level concurrency primitives 3) replace concurrent channels with the new implementation based on concurrent queues 4) add concurrent streams to the library of higher level concurrency primitives I was in a bit of a rush to write this up and post the code after finding out that the new Haskell platform will be released this month though it seems unlikely this would go in at this point - probably for the best as the code hasn't been tested much. I'm also not sure if concurrent streams would be more appropriate on Hackage? Thoughts and comments appreciated. Deadline: 8th of June. Ivan

2 2

Should folds in containers package remain INLINE
by Milan Straka 08 May '12

08 May '12

Hi all, this came up when discussing increasing size of GHC binary. Currently all folds in containers package are marked as INLINE. This has following effects: 1) the code using folds can be (much) more efficient -- for example, when calling statically known function. If the unfolding of that function is available, GHC can spot strictness and unbox values -- so `foldl (+) (0::Int)` evaluated the sum strictly and without allocating space for intermediate Ints. 2) the resulting binary size increases. If the folds in containers package are not INLINEd, the stripped GHC binary shrinks by 303kB, which is 0.8% of its size. Therefore we have speed vs. code size trade-off. FYI, Prelude.foldr is always inlined, Prelude.foldl is inlined only when GHC thinks it is worth it. Simon Marlow suggested that folds could be marked INLINABLE. Then they would probably not be inlined automatically, but one could say inline foldr to inline the fold on the call sites she chooses. Personally I am a bit in favor of keeping the folds INLINE. That allows the users of containers to get best performance without any change to the code (i.e., adding explicit `inline`). The price to pay is code size increase, which I consider minor (0.8% for GHC binary). Any other thoughts? Cheers, Milan

7 12

ANNOUNCE: hF2-0.1
by Marcel Fourné 07 May '12

07 May '12

Hi, this is the first release of hF2, a new F(2^e) backend for cryptographic code, to be found at http://hackage.haskell.org/package/hF2 (or simply by "cabal install hF2") This library is intended to be portable, somewhat timing-attack resilient and it's interface is geared toward the use in the "hecc" library (others may follow). Right now it uses unboxed Bit-Vectors (see: "bitvec") and with this the "vector" library, which seems to be the focus of optimization in array-like datastructures. The datatype "F2" is intended to hide the implementation from it's users, so repa/DPH or other implementations may provide parallelization for the arrays - they are just so obviously parallel, but the first prototype with this was painstakingly slow (...yes, that was my fault). Have fun with this, I sure did! Marcel -- Marcel Fourné OpenPGP-Key-ID: 4991 8AA4 202F 12AC 41F7 6C77 CA83 BDF0 7454 5C72 A good library is preferable to a tool, except when you just need that one tool.

1 0

ANNOUNCE: hecc-0.3.3
by Marcel Fourné 07 May '12

07 May '12

Hi again, this weekend there was (among other things) another release of hecc, the Elliptic Curve Cryptography Library for Haskell, to be found at http://hackage.haskell.org/package/hecc (or simply by "cabal install hecc") This release of hecc uses a new library (hF2), which abstracts the whole F(2^e). Please refer to that library for more information. With this release, the whole functionality of hecc should be usable again and the F2-using functions should be a bit faster now (but: not fast per se, especially if compared against other implementations). Feel free to play around with it and try to make it faster, I plan to do the same. ;-) As always: It is in development and may change, expect only crypto-api instances to be somewhat stable (someday). A fresh start into the new week, Marcel -- Marcel Fourné OpenPGP-Key-ID: 4991 8AA4 202F 12AC 41F7 6C77 CA83 BDF0 7454 5C72 A good library is preferable to a tool, except when you just need that one tool.

1 0

haskeline should also work with new mt-2.1.1
by Christian Maeder 28 Apr '12

28 Apr '12

Hi, trying to install haskeline together with other packages using cabal-install-0.14.0 resulted in a failure due to a too restrictive constraint. > cabal install mtl haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): haskeline-0.4 # because mtl-2.1.1 is already installed This installation of haskeline-0.4 fails! > cabal install transformers haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): mtl-1.1.1.1 haskeline-0.6.4.6 # transformers-0.3.0.0 is already installed > cabal install haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): transformers-0.2.2.0 mtl-2.0.1.0 haskeline-0.6.4.6 Cheers Christian

2 1

Proposal: Add newUniqueSTM to Data.Unique
by Edward Kmett 27 Apr '12

27 Apr '12

Data.Unique's newUnique uses atomically internally to update a TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a Unique within an STM transaction blows you sky high. The proposal is to split the definition of newUnique into: newUnique = atomically newUniqueSTM and expose newUniqueSTM. Alternately, since bug #3838 has been resolved, we could revert to using an IORef, which would avoid the wart of having us have an overtly IO action detonate because of an internal implementation detail of using STM. Since, there are two paths forward, I haven't put forward a patch, but wanted to open a discussion. Discussion Period: 2 weeks. -Edward Kmett

6 12

Concurrent collections
by Simon Peyton-Jones 24 Apr '12

24 Apr '12

I went to Aleksandar Prokopec's talk about Concurrent Tries at the Scala day earlier this week. I thought it was pretty cool. Here's the paper. http://infoscience.epfl.ch/record/166908/files/ctries-techreport.pdf http://lampwww.epfl.ch/~prokopec/ctries-snapshot.pdf Maybe we should have a Haskell version? Maybe we already do? Simon

5 5

Re: [Haskell] Types of when and unless in Control.Monad
by Henning Thielemann 22 Apr '12

22 Apr '12

moving to libraries, again ... On Sun, 22 Apr 2012, Julian Gilbey wrote: > On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote: >> On 21/04/2012, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: >> > to avoid silly "return ()" statements like in >> > >> > when cond $ do >> > monadicComputationWhoseResultIWantToDiscard >> > return () >> >> (when cond ∘ void) monadicComputationWhoseResultIWantToDiscard >> or >> when cond $ () <$ monadicComputationWhoseResultIWantToDiscard > > How is that simpler than > > when cond monadicComputationWhoseResultIWantToDiscard > > which it would be with the suggested new type? The original poster wanted to make it simpler, others want to let it be safer.

1 0