ANN: deepseq-bounded 0.5 - 0.6
This may affect depending code. Please consult the distro changelog for specific information about how your code might be affected, or better yet, refer to http://www.fremissant.net/deepseq-bounded/transition-5-6-7.html and http://www.fremissant.net/deepseq-bounded/grammar.html This is a transitional version of deepseq-bounded, with stability of the grammar expected in early March for version 0.7. This also causes major version bumps to the seqaid and leaky packages. To update everything, issue cabal update cabal install --reinstall --force-reinstalls seqaid which reinstalls the latest deepseq-bounded in passing. And also if you were to run seqaid demo it will use the updated version of leaky, so everything's up to date. The homepage for these projects starts at http://www.fremissant.net/deepseq-bounded-seqaid-leaky.html Kind Regards, Andrew ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: deepseq-bounded, seqaid, leaky
Finally, in case the lack of constraints on dependencies put anyone off, please note that all deps in all three projects now have minimum and maximum bounds. Also, I should take this chance to note that there were no cache controls in the homepages linked above, so please force reloads in your browser to see latest versions. (The pages /now/ have caching prevention so this should not be necessary again.) And, it's nice to share your thoughts, don't you think? -Andrew On Fri, Dec 19, 2014 at 8:01 AM, Andrew Seniuk ras...@gmail.com wrote: Sorry, that was my first Reddit post and I messed up. Please use this link http://www.reddit.com/r/haskell/comments/2pscxh/ann_deepseqbounded_seqaid_leaky/ -Andrew On Fri, Dec 19, 2014 at 7:07 AM, Andrew Seniuk ras...@gmail.com wrote: This trio of related packages explores strictness control in a variety of ways. deepseq-bounded provides classes and generic functions to artificially force evaluation, to extents controlled by static or dynamic configuration. seqaid puts that into practise, providing a GHC plugin to auto-instrument your package with a strictness harness, which is dynamically optimisable during runtime. This is supported directly in the GHC compilation pipeline, without requiring (or performing!) any edits to your sources. leaky is a minimal, prototypic executable that leaks space under current state-of-the-art compilation (GHC 7.8.3 -O2, at the present time). deepseq-bounded hackage: https://hackage.haskell.org/package/deepseq-bounded homepage: http://www.fremissant.net/deepseq-bounded seqaid hackage: https://hackage.haskell.org/package/seqaid homepage: http://www.fremissant.net/seqaid leaky hackage: https://hackage.haskell.org/package/leaky homepage: http://www.fremissant.net/leaky Reddit discussion for the three together: http://www.reddit.com/r/haskell/comments/2ps8f5/ann_deepseqbounded_seqaid_leaky/ Easiest way to try them all, is to install seqaid and run the demo: cabal install seqaid seqaid demo This tests seqaid on a local copy of the leaky source package. It turned out to be routine to extend deepseq-bounded and seqaid to dynamically configurable parallelisation (paraid?). Many other wrappers could be explored, too! Maybe seqaid should be renamed to koolaid or something... It's a pretty complicated system, and just first release, so there's bound to be lots of problems. I've not set up a bug tracker, but will maintain a casual list of bugs and feature requests at http://www.fremissant.net/seqaid/trac and will set up a proper tracker if there's interest. Any isssues (or comments), I'm here, or on the reddit discussion (or email). Andrew Seniuk rasfar on #haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANN: deepseq-bounded, seqaid, leaky
This trio of related packages explores strictness control in a variety of ways. deepseq-bounded provides classes and generic functions to artificially force evaluation, to extents controlled by static or dynamic configuration. seqaid puts that into practise, providing a GHC plugin to auto-instrument your package with a strictness harness, which is dynamically optimisable during runtime. This is supported directly in the GHC compilation pipeline, without requiring (or performing!) any edits to your sources. leaky is a minimal, prototypic executable that leaks space under current state-of-the-art compilation (GHC 7.8.3 -O2, at the present time). deepseq-bounded hackage: https://hackage.haskell.org/package/deepseq-bounded homepage: http://www.fremissant.net/deepseq-bounded seqaid hackage: https://hackage.haskell.org/package/seqaid homepage: http://www.fremissant.net/seqaid leaky hackage: https://hackage.haskell.org/package/leaky homepage: http://www.fremissant.net/leaky Reddit discussion for the three together: http://www.reddit.com/r/haskell/comments/2ps8f5/ann_deepseqbounded_seqaid_leaky/ Easiest way to try them all, is to install seqaid and run the demo: cabal install seqaid seqaid demo This tests seqaid on a local copy of the leaky source package. It turned out to be routine to extend deepseq-bounded and seqaid to dynamically configurable parallelisation (paraid?). Many other wrappers could be explored, too! Maybe seqaid should be renamed to koolaid or something... It's a pretty complicated system, and just first release, so there's bound to be lots of problems. I've not set up a bug tracker, but will maintain a casual list of bugs and feature requests at http://www.fremissant.net/seqaid/trac and will set up a proper tracker if there's interest. Any isssues (or comments), I'm here, or on the reddit discussion (or email). Andrew Seniuk rasfar on #haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: deepseq-bounded, seqaid, leaky
Sorry, that was my first Reddit post and I messed up. Please use this link http://www.reddit.com/r/haskell/comments/2pscxh/ann_deepseqbounded_seqaid_leaky/ -Andrew On Fri, Dec 19, 2014 at 7:07 AM, Andrew Seniuk ras...@gmail.com wrote: This trio of related packages explores strictness control in a variety of ways. deepseq-bounded provides classes and generic functions to artificially force evaluation, to extents controlled by static or dynamic configuration. seqaid puts that into practise, providing a GHC plugin to auto-instrument your package with a strictness harness, which is dynamically optimisable during runtime. This is supported directly in the GHC compilation pipeline, without requiring (or performing!) any edits to your sources. leaky is a minimal, prototypic executable that leaks space under current state-of-the-art compilation (GHC 7.8.3 -O2, at the present time). deepseq-bounded hackage: https://hackage.haskell.org/package/deepseq-bounded homepage: http://www.fremissant.net/deepseq-bounded seqaid hackage: https://hackage.haskell.org/package/seqaid homepage: http://www.fremissant.net/seqaid leaky hackage: https://hackage.haskell.org/package/leaky homepage: http://www.fremissant.net/leaky Reddit discussion for the three together: http://www.reddit.com/r/haskell/comments/2ps8f5/ann_deepseqbounded_seqaid_leaky/ Easiest way to try them all, is to install seqaid and run the demo: cabal install seqaid seqaid demo This tests seqaid on a local copy of the leaky source package. It turned out to be routine to extend deepseq-bounded and seqaid to dynamically configurable parallelisation (paraid?). Many other wrappers could be explored, too! Maybe seqaid should be renamed to koolaid or something... It's a pretty complicated system, and just first release, so there's bound to be lots of problems. I've not set up a bug tracker, but will maintain a casual list of bugs and feature requests at http://www.fremissant.net/seqaid/trac and will set up a proper tracker if there's interest. Any isssues (or comments), I'm here, or on the reddit discussion (or email). Andrew Seniuk rasfar on #haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
On 12/11/2012 16:56, Simon Hengel wrote:
Did you try -fpedantic-bottoms?
I just tried. The exception (or seq?) is still optimized away.
Here is what I tried:
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs ./Foo echo bar
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Linking Foo ...
bar
Sounds like a bug, -fpedantic-bottoms should work here. Please open a
ticket.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Sounds like a bug, -fpedantic-bottoms should work here. Please open a ticket. done [1]. [1] http://hackage.haskell.org/trac/ghc/ticket/7411 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Did you try -fpedantic-bottoms? Cheers, Simon On 08/11/2012 19:16, Edward Z. Yang wrote: It looks like the optimizer is getting confused when the value being evaluated is an IO action (nota bene: 'evaluate m' where m :: IO a is pretty odd, as far as things go). File a bug? Cheers, Edward Excerpts from Albert Y. C. Lai's message of Thu Nov 08 10:04:15 -0800 2012: On 12-11-08 01:01 PM, Nicolas Frisby wrote: And the important observation is: all of them throw A if interpreted in ghci or compiled without -O, right? Yes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
On 12-11-12 11:34 AM, Simon Marlow wrote:
Did you try -fpedantic-bottoms?
Interesting option. And furthermore its doc refers to -fno-state-hack, too.
import Control.DeepSeq
import Control.Exception
main = do
evaluate (('a' : error A) `deepseq` putStrLn hi)
throwIO (userError B)
-O -fpedantic-bottoms = B
-O -fno-state-hack = A
-O both = A
7.4.2, linux 32-bit x86
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Did you try -fpedantic-bottoms?
I just tried. The exception (or seq?) is still optimized away.
Here is what I tried:
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs ./Foo echo bar
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Linking Foo ...
bar
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Hi Edward,
thanks a lot for your reply.
rnf can be thought of a function which produces a thunk (for unit)
which, when forced, fully evaluates the function. With this in hand,
it's pretty clear how to use evaluate to enforce ordering:
evaluate (rnf ('a': throw exceptionA))
So if I understand correctly, then if I have
evaluate (x_1 `seq` x_2 `seq` x_3 `seq` ... `seq` x_n)
throwIO exceptionB
it is guaranteed that exceptionB can only happens if none of the xs are
exceptional.
I was just going to say that I can give at least one counterexample
where this does not hold:
evaluate (('a' : undefined) `deepseq` return () :: IO ())
throwIO exceptionB
But then I realized that here exceptionA is optimized away altogether.
For me this smells like a bug. Is this related to [1]?
Cheers,
Simon
[1] http://hackage.haskell.org/trac/ghc/ticket/2273
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
On 12-11-08 07:12 AM, Simon Hengel wrote:
I was just going to say that I can give at least one counterexample
where this does not hold:
evaluate (('a' : undefined) `deepseq` return () :: IO ())
throwIO exceptionB
But then I realized that here exceptionA is optimized away altogether.
For me this smells like a bug. Is this related to [1]?
[1] http://hackage.haskell.org/trac/ghc/ticket/2273
Interesting. A few more tests (all GHC 7.4.2, linux, x86 32-bit, use
ghc -O to compile):
The following cases throw A:
import Control.DeepSeq
import Control.Exception
main = do
evaluate (('a' : error A) `deepseq` return () :: Maybe ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` True)
throwIO (userError B)
main = do
x - evaluate (('a' : error A) `deepseq` putStrLn hi)
x
throwIO (userError B)
The following cases throw B:
main = do
evaluate (('a' : error A) `deepseq` return () :: IO ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` putStrLn hi)
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` getLine)
throwIO (userError B)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
And the important observation is: all of them throw A if interpreted in
ghci or compiled without -O, right?
On Thu, Nov 8, 2012 at 11:24 AM, Albert Y. C. Lai tre...@vex.net wrote:
On 12-11-08 07:12 AM, Simon Hengel wrote:
I was just going to say that I can give at least one counterexample
where this does not hold:
evaluate (('a' : undefined) `deepseq` return () :: IO ())
throwIO exceptionB
But then I realized that here exceptionA is optimized away altogether.
For me this smells like a bug. Is this related to [1]?
[1]
http://hackage.haskell.org/**trac/ghc/ticket/2273http://hackage.haskell.org/trac/ghc/ticket/2273
Interesting. A few more tests (all GHC 7.4.2, linux, x86 32-bit, use ghc
-O to compile):
The following cases throw A:
import Control.DeepSeq
import Control.Exception
main = do
evaluate (('a' : error A) `deepseq` return () :: Maybe ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` True)
throwIO (userError B)
main = do
x - evaluate (('a' : error A) `deepseq` putStrLn hi)
x
throwIO (userError B)
The following cases throw B:
main = do
evaluate (('a' : error A) `deepseq` return () :: IO ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` putStrLn hi)
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` getLine)
throwIO (userError B)
__**_
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.**org Glasgow-haskell-users@haskell.org
http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
On 12-11-08 01:01 PM, Nicolas Frisby wrote: And the important observation is: all of them throw A if interpreted in ghci or compiled without -O, right? Yes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
It looks like the optimizer is getting confused when the value being evaluated is an IO action (nota bene: 'evaluate m' where m :: IO a is pretty odd, as far as things go). File a bug? Cheers, Edward Excerpts from Albert Y. C. Lai's message of Thu Nov 08 10:04:15 -0800 2012: On 12-11-08 01:01 PM, Nicolas Frisby wrote: And the important observation is: all of them throw A if interpreted in ghci or compiled without -O, right? Yes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Is this related to imprecise exceptions?
http://research.microsoft.com/en-us/um/people/simonpj/papers/imprecise-exn.htm
Antoine
On Thu, Nov 8, 2012 at 12:01 PM, Nicolas Frisby nicolas.fri...@gmail.comwrote:
And the important observation is: all of them throw A if interpreted in
ghci or compiled without -O, right?
On Thu, Nov 8, 2012 at 11:24 AM, Albert Y. C. Lai tre...@vex.net wrote:
On 12-11-08 07:12 AM, Simon Hengel wrote:
I was just going to say that I can give at least one counterexample
where this does not hold:
evaluate (('a' : undefined) `deepseq` return () :: IO ())
throwIO exceptionB
But then I realized that here exceptionA is optimized away altogether.
For me this smells like a bug. Is this related to [1]?
[1]
http://hackage.haskell.org/**trac/ghc/ticket/2273http://hackage.haskell.org/trac/ghc/ticket/2273
Interesting. A few more tests (all GHC 7.4.2, linux, x86 32-bit, use ghc
-O to compile):
The following cases throw A:
import Control.DeepSeq
import Control.Exception
main = do
evaluate (('a' : error A) `deepseq` return () :: Maybe ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` True)
throwIO (userError B)
main = do
x - evaluate (('a' : error A) `deepseq` putStrLn hi)
x
throwIO (userError B)
The following cases throw B:
main = do
evaluate (('a' : error A) `deepseq` return () :: IO ())
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` putStrLn hi)
throwIO (userError B)
main = do
evaluate (('a' : error A) `deepseq` getLine)
throwIO (userError B)
__**_
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.**org Glasgow-haskell-users@haskell.org
http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Using DeepSeq for exception ordering
Hi,
I'm puzzled whether it is feasible to use existing NFData instances for
exception ordering.
Here is some code that won't work:
return $!! 'a' : throw exceptionA
throwIO exceptionB
Here GHC makes a non-deterministic choice between exceptionA and
exceptionB. The reason is that the standard DeepSeq instances use
`seq`, and `seq` does not help with exception ordering**.
I tried several things (ghc-7.4.2 with -O2), and the following seems to
order the exceptions for this particular case:
(evaluate . force) ('a' : throw exceptionA)
throwIO exceptionB
But I'm a little bit worried that this may not hold in general, e.g.
(return $!! 'a' : throw exceptionA) = evaluate
throwIO exceptionB
results in exceptionB. I think my main issue here is that I do not
properly understand how seq and seq# (which is used by evaluate) do
interact with each other. And how I can reason about code that uses
both.
The question is really whether it is somehow feasible to use existing
NFData instances to order exceptions. Or would we need to define a
separate type class + instances for that, e.g.:
class DeepEvaluate a where
deepEvaluate :: a - IO a
deepEvaluate = evaluate
instance DeepEvaluate Char where
instance DeepEvaluate a = DeepEvaluate [a] where
deepEvaluate = mapM deepEvaluate
If you have any related ideas or thoughts, I'd love to hear about them.
Cheers,
Simon
** This is desired behavior, see the discussion at
http://hackage.haskell.org/trac/ghc/ticket/5129
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Hello Simon,
I think the confusion here is focused on what exactly it is that
the NFData class offers:
class NFData a where
rnf :: a - ()
rnf can be thought of a function which produces a thunk (for unit)
which, when forced, fully evaluates the function. With this in hand,
it's pretty clear how to use evaluate to enforce ordering:
evaluate (rnf ('a': throw exceptionA))
One could imagine defining:
deepSeqEvaluate :: NFData a = a - IO ()
deepSeqEvaluate = evaluate . rnf
In general, the right way to think about the semantics here is to
distinguish between evaluation as an explicit effect (evaluate) and
evaluation as a side effect of running IO (when you x `seq` return ()).
They're distinct, and the latter doesn't give you ordering guarantees.
This applies even when DeepSeq is involved.
Cheers,
Edward
Excerpts from Simon Hengel's message of Wed Nov 07 05:49:21 -0800 2012:
Hi,
I'm puzzled whether it is feasible to use existing NFData instances for
exception ordering.
Here is some code that won't work:
return $!! 'a' : throw exceptionA
throwIO exceptionB
Here GHC makes a non-deterministic choice between exceptionA and
exceptionB. The reason is that the standard DeepSeq instances use
`seq`, and `seq` does not help with exception ordering**.
I tried several things (ghc-7.4.2 with -O2), and the following seems to
order the exceptions for this particular case:
(evaluate . force) ('a' : throw exceptionA)
throwIO exceptionB
But I'm a little bit worried that this may not hold in general, e.g.
(return $!! 'a' : throw exceptionA) = evaluate
throwIO exceptionB
results in exceptionB. I think my main issue here is that I do not
properly understand how seq and seq# (which is used by evaluate) do
interact with each other. And how I can reason about code that uses
both.
The question is really whether it is somehow feasible to use existing
NFData instances to order exceptions. Or would we need to define a
separate type class + instances for that, e.g.:
class DeepEvaluate a where
deepEvaluate :: a - IO a
deepEvaluate = evaluate
instance DeepEvaluate Char where
instance DeepEvaluate a = DeepEvaluate [a] where
deepEvaluate = mapM deepEvaluate
If you have any related ideas or thoughts, I'd love to hear about them.
Cheers,
Simon
** This is desired behavior, see the discussion at
http://hackage.haskell.org/trac/ghc/ticket/5129
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DeepSeq
DrIFT can derive 'rnf' or reduce to normal form for arbitrary classes which is similar to deepSeq, in fact does anyone have a good description as to how they are different? John On Fri, Jul 19, 2002 at 12:31:40PM +0100, Jorge Adriano wrote: On Friday 19 July 2002 12:10, George Russell wrote: Would it be possible to bring the DeepSeq library into the libraries distributed with GHC? (I think Dean Herington is responsible for it.) Of course it's easy enough to drop it into one's own program (I am just about to do this) but (1) It is fairly common to want to force deeper evaluation. (2) DeepSeq is simple enough to be dropped in the GHC distribution, without it causing much trouble or making it much bigger. (3) At the same time, it is not so simple that it can be reimplemented in a couple of lines. Agree. Beeing able to derive instances of DeepSeq would be nice too. J.A. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
DeepSeq
Would it be possible to bring the DeepSeq library into the libraries distributed with GHC? (I think Dean Herington is responsible for it.) Of course it's easy enough to drop it into one's own program (I am just about to do this) but (1) It is fairly common to want to force deeper evaluation. (2) DeepSeq is simple enough to be dropped in the GHC distribution, without it causing much trouble or making it much bigger. (3) At the same time, it is not so simple that it can be reimplemented in a couple of lines. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DeepSeq
On Friday 19 July 2002 12:10, George Russell wrote: Would it be possible to bring the DeepSeq library into the libraries distributed with GHC? (I think Dean Herington is responsible for it.) Of course it's easy enough to drop it into one's own program (I am just about to do this) but (1) It is fairly common to want to force deeper evaluation. (2) DeepSeq is simple enough to be dropped in the GHC distribution, without it causing much trouble or making it much bigger. (3) At the same time, it is not so simple that it can be reimplemented in a couple of lines. Agree. Beeing able to derive instances of DeepSeq would be nice too. J.A. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DeepSeq
Beeing able to derive instances of DeepSeq would be nice too.
Here is an implementation using GHC's derivable type classes.
Cheers, Ralf
ghc -c -fglasgow-exts -fgenerics -package lang Eval.lhs
module Force
where
import Generics
class Force a where
force :: a - ()
force{|Unit|} a = a `seq` ()
force{|b :+: c|} a = case a of
Inl b - force b
Inr c - force c
force{|b :*: c|} a = case a of
b :*: c - force b `seq` force c
instance Force Char where
force a = a `seq` ()
instance Force Int where
force a = a `seq` ()
eval :: (Force a) = a - a
eval a= force a `s
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
