- Libraries - Haskell.org

haddock, instances and defining modules
by Daniel Gorín 18 Oct '12

18 Oct '12

Hi The haddock page for Data.Either lists an instance Functor (Either a). However, this instance doesn't get in scope when importing Data.Either. E.g., the following program fails to compile: > import Data.Either > > main = print $ fmap not $ Right "hello" AFAIK, one needs to import Control.Monad.Instances instead to get such an instance; but there is nothing in the haddock page of Data.Either that suggests it. This can be quite frustrating for beginners! It would be good if the docs could be improved here, but I'm not sure what to suggest (maybe haddock should be generating something else in these cases?)… Any thoughts? Thanks, Daniel

4 4

Adding dataCast1 and dataCast2 methods to the Data instances of Ptr, ForeignPtr, and Array
by José Pedro Magalhães 17 Oct '12

17 Oct '12

Hello all, This email is to draw your attention to http://hackage.haskell.org/trac/ghc/ticket/7256. Missing dataCast1 and dataCast2 methods in Data instances results in incorrect behaviour when using SYB's ext1/ext2 functions. The proposed fix adds the methods, but it requires adding additional Data constraints to these instances. Here's the relevant part of the diff: -instance Typeable a => Data (Ptr a) where > +instance (Data a, Typeable a) => Data (Ptr a) where > > -instance Typeable a => Data (ForeignPtr a) where > +instance (Data a, Typeable a) => Data (ForeignPtr a) where > > -instance (Typeable a, Data b, Ix a) => Data (Array a b) > +instance (Typeable a, Data a, Data b, Ix a) => Data (Array a b) > Does anyone find this change problematic? Cheers, Pedro

1 0

Foldable & Traversable instances for ((,) a)
by Merijn Verstraaten 15 Oct '12

15 Oct '12

I noticed (to my great dismay!) that ((,) a) doesn't appear to have Foldable or Traversable instance anywhere, even though it is an (almost trivial) instance of both: instance Foldable ((,) a) where foldMap f (_, x) = f x instance Traversable ((,) a) where traverse f (a, x) = (,) a <$> f x I guess the most appropriate place for either would be Data.Tuple of Data.Foldable and Data.Traversable respectively. Kind regards, Merijn Verstraaten

7 8

Strictness of modify in Control.Monad.State.Strict
by Ben Gamari 12 Oct '12

12 Oct '12

Is there a reason there is no `modify` operation in Control.Monad.State.Strict (and the transformers analogue) which is truly strict in the state? That is, modify' :: Monad m => (a -> a) -> StateM a m () modify' f = get >>= (\x -> put $! f x) While this is admittedly not a difficult piece of code to write, even the suggestion in the documentation that `modify` isn't as strict as one might think would likely save many man-hours of debugging (especially for those who are less familiar with the language, for whom, speaking from experience, strictness issues can pose a major hurdle to adoption) In general it would be nice if the notion of strictness were better addressed in the major libraries' documentation. It's a nuanced issue which is not fully captured by a ".Lazy" or ".Strict" in the module name. Just a thought. Thanks, - Ben

4 4

ANN: data-dword: Long binary words from short ones
by Mikhail Vorozhtsov 11 Oct '12

11 Oct '12

Hi. I'm pleased to announce my new little library, data-dword[1]. It provides Template Haskell utilities for defining binary word data types from low and high halves, e.g. data Word96 = Word96 Word32 Word64 -- strictness is configurable data Int96 = Int96 Int32 Word64 -- All instances are fully implemented (including `quotRem`, etc) instance Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, Ix, Bits, Hashable -- Extra bit-manipulating functions, unwrapped addition and -- multiplication, etc. instance BinaryWord, DoubleWord -- Rewrite rules for converting to/from the standard integral types {-# RULES "fromIntegral/..." ... #-} The library comes with a pretty thorough test suite (that ATM has some failures on x86-32 due to bug #7233[2] in the base library). [1] http://hackage.haskell.org/package/data-dword [2] http://hackage.haskell.org/trac/ghc/ticket/7233

2 2

Haskell Platform proposal: Add the vector package
by Johan Tibell 08 Oct '12

08 Oct '12

Hi, I am, with Roman's support, making a formal proposal to have the vector package included in the Haskell Platform: http://trac.haskell.org/haskell-platform/wiki/Proposals/vector See the wiki page for details, and a list of open issues for discussion. The vector package itself can be found on Hackage: http://hackage.haskell.org/package/vector I have set the deadline to 13 August 2012 (~2 months' time), with comments due by 13 July 2012 (~one month). There's plenty of time before the next platform release anyway (scheduled for 12 November 2012). -- Johan

16 82

Stricter WriterT monad transformer
by Gabriel Gonzalez 05 Oct '12

05 Oct '12

This is a suggestion I initially ran by Ross and he recommended that I post it to this mailing list. Here's the problem: WriterT always leaks space. I've tested three ways to fix the space leak, and only one works: * [DOES NOT WORK] Add a strictness annotation to the Monad instance for WriterT * [DOES NOT WORK] Use the StateT monad transformer *without* a strictness annotation * [WORKS] Use the StateT monad transformer *with* a strictness annotation I've hpasted the three different approaches and their test cases so you all can test it for yourselves: http://hpaste.org/75837 I'm requesting this because I need a WriterT monad transformer that does not leak space for defining folds for my pipes library. I can temporarily define the correct one within my own library but in the long run I believe it belongsin transformers. I also discovered another subtle advantage of using StateT to simulate WriterT. The traditional WriterT monad instance punishes the case where you use a free monad as the base monad because of the following bind in its monad instance: instance (Monad m, Monoid w) => Monad (WriterT w m) where return a = WriterT2 $ return (a, mempty) m >>= f = WriterT2 $ do (a, w) <- runWriterT m (b, w') <- runWriterT (k a) <= This bind is the problem return (b, w `mappend` w') This bind triggers a quadratic blowup when the base monad is a free monad, whereas the StateT simulation of WriterT runs in linear time. For these reasons, I suggest adding a "Control.Monad.Trans.Writer.Stricter" module to "transformers" that implements WriterT using the "WriterT4" implementation from the above hpaste.

3 3

Re: Changes to Typeable
by Dan Burton 05 Oct '12

05 Oct '12

Whoops, sending this to the whole list. Sorry for the duplication, Simon. -- Dan Burton ---------- Forwarded message ---------- From: Dan Burton <danburton.email(a)gmail.com> Date: Fri, Oct 5, 2012 at 11:57 AM Subject: Re: Changes to Typeable To: Simon Peyton-Jones <simonpj(a)microsoft.com> I was alluding to what Brent Yorgey and others already said. If I annotate a function with the type signature (a -> Int) then that function should *not* have access to typeable operations on its input (because then we would lose our precious free theorems). If a function is not annotated, but uses typeable operations, then type inference should indicate the corresponding Typeable constraints in the inferred type. To steal Brent's example: foo x = case typeOf x of Int -> (3 :: Int) Char -> 4 _ -> 5 This function (ignoring the monomorphism restriction) should be inferred to have the type Typeable a => a -> Int In short, from the language user's perspective, Typeable should still be a regular old typeclass, that just happens to come with a distinct instance for every type. Another way to model the "danger" of accessing Typeable information is to use a monad, and consider access to Typeable information to be an "effect".[1] For backwards compatibility, I think it would be easier to just stick with the typeclass. [1] http://hpaste.org/75824 -- Dan Burton Another, simpler alternative (if we don't want to use the Typeable typeclass or the Monad idea) is to simply prefix "unsafe" to all of the Typeable methods, and then quarentine them to a "contaminated" module as we have done with unsafePerformIO. On Fri, Oct 5, 2012 at 10:12 AM, Simon Peyton-Jones <simonpj(a)microsoft.com>wrote: > To take advantage of Typeable, though, the user should still have to > annotate the necessary Typeable constraints.**** > > ** ** > > Can you say what you mean by this? Perhaps with an example.**** > > ** ** > > Simon**** > > **** > > *From:* Dan Burton [mailto:danburton.email@gmail.com] > *Sent:* 05 October 2012 17:05 > > *To:* Simon Peyton-Jones > *Cc:* libraries(a)haskell.org > *Subject:* Re: Changes to Typeable**** > > ** ** > > Allowing users to write instances leads to potential un-soundness when > doing dynamic type casts, so it has always been a Bad Idea.**** > > ** ** > > Related to this, I'm sure several of us remember Bob Harper's blog post[1] > regarding exceptions that uses a hand-written Typeable instance. The ideal > scenario would be for the compiler to automatically derive Typeable for all > types, and completely disallow the user from providing hand-written > instances. To take advantage of Typeable, though, the user should still > have to annotate the necessary Typeable constraints. Whether this is > special-cased in the compiler for optimization is an implementation detail > and is largely irrelevant to the Haskell programmer; I say let's follow the > common Haskell mentality of making it correct first and fast second.**** > > ** ** > > Most typeclasses come with some "laws" that make them useful; I don't see > any documented laws for Typeable, but presumably there are some (e.g. no > type should say it is another type), and the compiler can automatically > derive instances that are guaranteed to follow them.**** > > ** ** > > It would be nice to be able to enforce typeclass laws on instances at > compile time, but that's stepping into theorem prover territory.**** > > ** ** > > [1] > http://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-un… > **** > > ** ** > > -- Dan Burton**** >

1 0

cabal update retrieves broken index: warp-1.3.3.x.cabal not readable
by Andreas Abel 05 Oct '12

05 Oct '12

Hi, I pulled the new 00-index.tar from hackage an hour ago with cabal update, breaking cabal install. cabal: Couldn't read cabal file "warp/1.3.3/warp.cabal" cabal: Couldn't read cabal file "warp/1.3.3.1/warp.cabal" Fix is $ tar -f 00-index.tar --delete warp/1.3.3 $ tar -f 00-index.tar --delete warp/1.3.3.1 My system: $ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.1 The cabal files for warp/1.3.3... need a fix, or be removed from hackage. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

4 3

Compilation of directory package on GHC 7.4
by Dominique Devriese 05 Oct '12

05 Oct '12

Dear maintainers, The directory package is currently not compiling on GHC 7.4, leading to a compile failure of packages that depend on it. Hackage has a build failure log for GHC 7.4. I propose the attached patch, although I have not tested it on GHC 7.6. Can this (or an alternative fix) please be considered? Thanks in advance, Dominique Devriese

4 4