- Libraries - Haskell.org

Proposal: adding 'tailDropWhile' to Data.List
by Kazu Yamamoto 30 Sep '11

30 Sep '11

Hello, Many languages provide the 'chop' or 'trip' function but Data.List does not. I would like to add a new function called 'tailDropWhile' so that people can easily implement 'chop' for String: chop :: String -> String chop = tailDropWhile isSpace The definition of tailDropWhile is as follows: {- wren ng thornton's version. This is lazier than Aoe's one. Out and inP implement push-down automata. -} tailDropWhile :: (a -> Bool) -> [a] -> [a] tailDropWhile p = out where out [] = [] out (x:xs) | p x = inP [x] xs | otherwise = x : out xs inP _ [] = [] inP ss (x:xs) | p x = inP (x:ss) xs | otherwise = reverse ss ++ x : out xs {- Mitsutoshi Aoe's version. This is faster is many cases but more strict. Just for reference. tailDropWhile :: (a -> Bool) -> [a] -> [a] tailDropWhile p = foldr go [] where go x xs | p x && null xs = [] | otherwise = x:xs -} For more information, please read: http://www.mail-archive.com/haskell-cafe@haskell.org/msg93192.html Discussion period: 2 weeks. Regards, --Kazu

11 20

Haskell Platform 2011.4.0.0 in July?
by Guy 29 Sep '11

29 Sep '11

The HP web page promises the next release (2011.4.0.0) in July 2011. Which time zone does this relate to?

4 3

patch: hpc test patch: add reqlib('unix') to hpc_fork test
by Bill Tutt 29 Sep '11

29 Sep '11

This makes hpc_fork an expected failure on Windows. Fyi, Bill diff --git a/tests/fork/test.T b/tests/fork/test.T index a045f2e..5349711 100644 --- a/tests/fork/test.T +++ b/tests/fork/test.T @@ -1,6 +1,7 @@ setTestOpts(compose(only_compiler_types(['ghc']), - compose(omit_ways(['ghci','threaded2']), - skip_if_fast))) + compose(reqlib('unix'), + compose(omit_ways(['ghci','threaded2']), + skip_if_fast)))) hpc_prefix = "perl ../hpcrun.pl --clear --exeext=" + config.exeext + " --hpc='" + config.hpc + "'";

1 0

Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
by Cale Gibbard 28 Sep '11

28 Sep '11

I just tried this in ghci-7.0.3: ghci> nubBy (>=) [1,2,3,4] [1] Think about what this is doing: it is excluding 2 from the list because 2 >= 1, rather than including it because 1 >= 2 fails. I think an important convention when it comes to higher order functions on lists is that to the extent which is possible, the function parameters take elements from the list (or things computed from those) in the order in which they occur in the original list. If we reimplement it in the obvious way: ghci> let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f xs) ghci> nubBy (>=) [1,2,3,4] [1,2,3,4] I'm aware that the Report (strangely!) explicitly leaves the behaviour of nubBy unspecified for functions which are not equivalence relations, but the behaviour given by the Report implementation (the opposite of the current behaviour in GHC) is useful and desirable nonetheless. I'm sure I've written about this before. I'm not entirely sure what happened to the previous thread of discussion about this, but it just came up again for me, and I decided that I was sufficiently irritated by it to post again. Another thing perhaps worth pointing out is that the parameters to mapAccumR have always been backwards (compare it with foldr). Few enough people use this function that I'm fairly sure we could just change it without harm. - Cale

5 8

Extracting constructor name
by Gracjan Polak 27 Sep '11

27 Sep '11

Hi all, To get a bit better error reporting and debugging I'd like to report constructor names misused. Example: data X = A | B Int | C String magic A = doSomething magic x = error $ "magic can only be used on A, you supplied " ++ constrName x I'm missing constrName that returns only constructor name as string, skips all fields (if any). -- Gracjan

4 3

Re: Libraries Digest, Vol 97, Issue 28
by John Lato 26 Sep '11

26 Sep '11

Message: 6 > Date: Mon, 26 Sep 2011 05:53:05 +0200 > From: Daniel Fischer <daniel.is.fischer(a)googlemail.com> > Subject: Proposal: New Eq and Ord instances for Double and Float > To: libraries(a)haskell.org > Message-ID: <201109260553.05083.daniel.is.fischer(a)googlemail.com> > Content-Type: Text/Plain; charset="us-ascii" > > Proposal: Provide Double and Float with Eq and Ord instances that introduce > a total order. With the current behavior, other data structures (e.g. Data.Set Float) can be corrupted by NaN. Silent corruption is an unforgivable sin, and I think it's worth giving up IEEE semantics for default comparisons to fix it. Especially since IEEE floats are often poorly-understand, it's an easy trap for the unwary, or even the cautious, programmer. My biggest concern is for the Haskell community at large. How many current programs expect (or rely upon) IEEE behavior? The impact of this change could be extremely wide-ranging. I would expect a major version bump to base to implement this, solely due to the impact. As to what symbol to use for IEEE comparisons, I dislike the OCaml dot-style operators precisely because it's easy to overlook. I don't have a nice justification for it, but how about two dots, e.g. "==..", ">.." ? John L

1 0

Re: Libraries Digest, Vol 97, Issue 28
by Howard B. Golden 26 Sep '11

26 Sep '11

On Mon, 26 Sep 2011 00:05:43 -0500 "Bryan O'Sullivan" <bos(a)serpentine.com> wrote: > On Sun, Sep 25, 2011 at 10:53 PM, Daniel Fischer < > daniel.is.fischer(a)googlemail.com> wrote: > > > Proposal: Provide Double and Float with Eq and Ord instances that introduce > > a total order. > > > > I am strongly against this proposal, as it is in an area that is > particularly poorly understood by most programmers (even experts). While the > current behaviour may be undesirable from some points of view, at least it > is consistent with most other programming languages - and this is one of the > few areas where I think that's important. I agree with BOS. If a totally ordered data type is desirable, it shouldn't be called Float or Double. To do so violates the principle of least astonishment. As far as the proposal is concerned, if the types have different names, then I agree mostly. However, it seems to me that such types _not_ include NaN, negative zero and the infinities, because they don't make mathematical sense. Instead, the types should be Maybes that treat those IEEE values as Nothing. IEEE Floats and Doubles are _somewhat_ understood by those who need them. The rest of us should be _very_ careful when using them!

1 0

Re: [patch] Don't detect libiconv/libcharset on Windows to avoid changing GHCs build behavior on windows with newer mingw installs
by Ian Lynagh 25 Sep '11

25 Sep '11

On Fri, Sep 16, 2011 at 07:10:13PM -0400, Bill Tutt wrote: > > If iconv is detected vector-0.8 fails to build because ghc can't find > iconv.dll. Patch applied, thanks! Thanks Ian

1 0

Why base 4.4.0.0 does not use default signatures extention (new in GHC 7.2)?
by Maciej Marcin Piechotka 23 Sep '11

23 Sep '11

Hello, While reading the list of changes in GHC 7.2 I noticed that default signatures extention have been added. Therefore following code compiles: > {-# LANGUAGE NoImplicitPrelude #-} > {-# LANGUAGE DefaultSignatures #-} > class Functor f where > fmap :: (a -> b) -> f a -> f b > default fmap :: Applicative f => (a -> b) -> f a -> f b > f `fmap` m = pure f <*> m > (<$) :: a -> f b -> f a > (<$) = fmap . const > > (<$>) = fmap > > class Functor f => Pointed f where > point :: a -> f a > default point :: Applicative f => a -> f a > point = pure > > class Pointed f => Applicative f where > pure :: a -> f a > default pure :: Monad f => a -> f a > pure = return > (<*>) :: f (a -> b) -> f a -> f b > default (<*>) :: Monad f => f (a -> b) -> f a -> f b > f <*> v = liftM2 ($) f v > (*>) :: f a -> f b -> f b > (*>) = liftA2 (const id) > (<*) :: f a -> f b -> f a > (<*) = liftA2 const > > class Applicative f => Monad f where > return :: a -> f a > (>>=) :: f a -> (a -> f b) -> f b > (>>) :: f a -> f b -> f b > m >> k = m >>= const k > > data List a = Empty | Cons a (List a) > > instance Monad List where > return x = Cons x Empty > Empty >>= _ = Empty > Cons x xs >>= f = Cons (f x) (xs >>= f) > > test = Empty <*> Empty > > ($) = \f v -> f v > liftA2 f a b = f <$> a <*> b > liftM2 f a b = f >>= \f' -> a >>= \a' -> b >>= \b'-> return (f' a' b') > const a _ = a > fix f = let x = f x in x > error _ = fix id > id x = x > f . g = \x -> f (g x) While the Functor f => (Pointed f =>) Applicative f => Monad f is still discussed the default methods would be a step towards the goal. Regards

3 3

documentation of difference between lazy and strict State monad
by Henning Thielemann 22 Sep '11

22 Sep '11

The confusion about the kind of strictness in lazy and strict State monad pops up again and again. How about illustrating the difference using these examples: Control.Monad.Trans.State.Lazy> evalState (mapM (\n -> modify (n+) >> get) [1::Integer ..]) 0 [1,3,6,10,15,21,28,36,45,55,66,78,91,105,120 ... Control.Monad.Trans.State.Strict> evalState (mapM (\n -> modify (n+) >> get) [1::Integer ..]) 0 <<wait infinitely>> ? Now, often I like to have a kind of strictness where lists can be processed lazily but the state is updated strictly between the list cells. E.g. the following expression cannot be computed both in lazy and in strict State monad: evalState (mapM (\n -> modify (n+) >> get) [1::Integer ..]) 0 !! 10000000 Since the list shall still be processed lazily, we must stay in the lazy State monad. But the state shall be updated strictly for every list cell. I can achieve this for instance by replacing 'mapM' by the following 'mapS': mapS :: (a -> State s b) -> [a] -> State s [b] mapS _ [] = gets (\s -> seq s []) mapS f (x:xs) = do y <- f x; s <- get; ys <- mapS f xs; return (seq s (y:ys)) Now evalState (mapS (\n -> modify (n+) >> get) [1::Integer ..]) 0 !! 10000000 can be computed with constant memory consumption.

2 2