On Mon, 12 Nov 2012, Bas van Dijk wrote:

On 12 November 2012 10:41, Henning Thielemann wrote:

...

There was already a discussion some weeks ago

Thanks, I missed that one. It seems it didn't reach a conclusion yet. Maybe we can continue the discussion here.

My impression is that making 'seq' available as function without a typeclass constraint was a step in the wrong direction. Then foldl' and friends were the second step in the wrong direction and scanl' would be the third step. For 'seq' I would propose we first start with a cleanly typed 'seq' and base foldl' functions on this function instead of the built-in 'seq'. But I assume that most of the time where foldl' is used, actually a deepseq-foldl' is meant. I have often seen foldl' in Haskell library code that had not the intended effect since the accumulator was a lazy pair or a Map.

On Mon, 12 Nov 2012, Bas van Dijk wrote:

On 12 November 2012 11:17, Henning Thielemann wrote:

...

My impression is that making 'seq' available as function without a typeclass constraint was a step in the wrong direction. Then foldl' and friends were the second step in the wrong direction and scanl' would be the third step. For 'seq' I would propose we first start with a cleanly typed 'seq' and base foldl' functions on this function instead of the built-in 'seq'.

I think I agree that putting seq in a type class would have been better (especially since we can now derive things generically). However if we are going to change this we have to change a lot of code anyway. Why not add these strict functions now and change all of them later (incl. all the strict functions in containers) when the Seq type class gets added (if that ever happens...)?

I don't think of changing it. We could provide a package that exports "the right 'seq'" and then encourage people to use this instead of Prelude.seq.

...

But I assume that most of the time where foldl' is used, actually a deepseq-foldl' is meant. I have often seen foldl' in Haskell library code that had not the intended effect since the accumulator was a lazy pair or a Map.

If your accumulator in foldl' is a lazy pair you should just seq the new elements before returning the pair. Not doing that is just silly. I don't see the need for deepseq there.

Silly or not, it is simple to forget it, especially if the foldl' was written once with a simple accumulator type which is later changed to a pair type.

In case your accumulator is a Map you really want to use foldl'.

Why not a deepseq foldl'?

On 12 November 2012 13:25, Henning Thielemann wrote:

I don't think of changing it. We could provide a package that exports "the right 'seq'" and then encourage people to use this instead of Prelude.seq.

I think I like this idea. So the package would export something like: module Control.Seq where import Prelude hiding (seq) import GHC.Base hiding (seq) class WHNFData a where rwhnf :: a -> () instance WHNFData [a] where rwhnf [] = () rwhnf (_:_) = () -- and all the others... seq :: WHNFData a => a -> b -> b seq a b = case rwhnf a of () -> b ($!) :: WHNFData a => (a -> b) -> a -> b f $! x = x `seq` f x force :: WHNFData a => a -> a force x = x `seq` x -- Doesn't type check unfortunately -- since the b in seq :: a -> b -> b is of kind * and not #: -- evaluate :: WHNFData a => a -> IO a -- evaluate x = IO (\s -> x `seq` (# s, x #)) However, I still think it doesn't hurt to add the strict versions now. And then in the future possibly change the whole base library at once (and other libraries like containers) to support the Seq class. Bas

Henning Thielemann writes: [...]

...

force :: WHNFData a => a -> a force x = x `seq` x

Does this function do something?

if 'seq' adheres to the Haskell reports definition, that is seq ⊥ b = ⊥ seq a b = b, if a ≠ ⊥ 'seq a a' and 'a' must be equivalent, and thus 'force' has to be equivalent to a type-specialized 'id', i.e. force :: WHNFData a => a -> a force x = x

Yes, GHC will rewrite this to force x = x I'm also not sure if we really want "seq" in all of these cases, or if we want stronger guarantees. For example, GHC can (and often will) rewrite f x y = x `seq` y `seq` x to f x y = y `seq` x This changes the order of evaluation. For pure computations this is semantically sound. However, it can change the space behaviour of the program, which defeats the point of using "seq" in the first place (usually). If forcing "x" to be evaluated before "y" is the goal, then "pseq" must be used. I think it's worthwhile to consider introducing high-level combinators for this use case as well. On 15 November 2012 15:38, Johan Tibell wrote:

On Thu, Nov 15, 2012 at 2:38 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

On Mon, 12 Nov 2012, Bas van Dijk wrote:

...

force :: WHNFData a => a -> a force x = x `seq` x

Does this function do something?

No. It says "when x is evaluated, evaluate x".

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Push the envelope. Watch it bend.

Hi, On Mon, Nov 12, 2012 at 12:02:28PM +0100, Bas van Dijk wrote:

On 12 November 2012 11:34, Bas van Dijk wrote:

...

I just realized that mapAccumL' is not needed since the caller has the ability to force the accumlator. So please ignore that part of my proposal. This leaves just scanl' and scanl1' as orignally proposed by Niklas Hambüchen.

Oops scrap that. After thinking about it more and testing it I realize the caller really doesn't have control over the evaluation order in the function passed to mapAccumL. So please consider my original proposal again.

scanl' and scanl1' can be naturally defined using their non-strict counterparts like: scanl' :: (b -> a -> b) -> b -> [a] -> [b] scanl' f z xs = headStrict $ scanl f z xs scanl1' :: (a -> a -> a) -> [a] -> [a] scanl1' f xs = headStrict $ scanl1 f xs headStrict :: [a] -> [a] headStrict = foldr (\x y -> seq x (x : y)) [] So the `headStrict' function could be exported from Data.List instead. A nice thing about it is that it can also be used with other list-generating functions like `iterate' to make it strict. It's also possible to define mapAccumL' in terms of mapAccumL, but the corresponding forcing function would not look as nice as `headStrict' above, so I would think providing mapAccumL' is a good idea. Regards, Takano Akio

On 13 November 2012 11:06, Takano Akio wrote:

Hi,

On Mon, Nov 12, 2012 at 12:02:28PM +0100, Bas van Dijk wrote:

...

On 12 November 2012 11:34, Bas van Dijk wrote:

...

I just realized that mapAccumL' is not needed since the caller has the ability to force the accumlator. So please ignore that part of my proposal. This leaves just scanl' and scanl1' as orignally proposed by Niklas Hambüchen.

Oops scrap that. After thinking about it more and testing it I realize the caller really doesn't have control over the evaluation order in the function passed to mapAccumL. So please consider my original proposal again.

scanl' and scanl1' can be naturally defined using their non-strict counterparts like:

scanl' :: (b -> a -> b) -> b -> [a] -> [b] scanl' f z xs = headStrict $ scanl f z xs

scanl1' :: (a -> a -> a) -> [a] -> [a] scanl1' f xs = headStrict $ scanl1 f xs

headStrict :: [a] -> [a] headStrict = foldr (\x y -> seq x (x : y)) []

So the `headStrict' function could be exported from Data.List instead. A nice thing about it is that it can also be used with other list-generating functions like `iterate' to make it strict.

It's also possible to define mapAccumL' in terms of mapAccumL, but the corresponding forcing function would not look as nice as `headStrict' above, so I would think providing mapAccumL' is a good idea.

Regards, Takano Akio

Thanks Takano, headStrict looks like a useful function. I would like to drop the proposal for adding scanl', scanl1' and mapAccumL'. Cheers, Bas