I'd be quite happy to rename the flag to GeneralisedisedListComp, and clarify
the user manual. Would that suit everyone?
I suppose the alternative is to leave it as TransformListComp, and document
that fact. But I rather agree that GeneralisedListComp fits the literature
better.
Simon
|
It sounds like a bad performance bug to me! Newtypes should not cost
efficiency. Please to submit a Trac bug report.
What would really help is a self-contained program that demonstrates the
problem. Maybe that's what you've supplied. I'm confused though. You say
If I remove any of
On Jun 4, 2009, at 10:05 AM, Simon Peyton-Jones wrote:
What would really help is a self-contained program that demonstrates
the problem. Maybe that's what you've supplied. I'm confused
though. You say
If I remove any of them (one is enough) then
the program finishes in
On 03/06/2009 22:26, Sebastian Fischer wrote:
---
{-# LANGUAGE RankNTypes #-}
newtype S a = S { unS :: forall b . (a - Int - [b]) - Int - [b] }
ret x = S (\c - c x)
a `bind` f = S (\c - unS a (\x - unS (f x) c))
zero = S (\c _ - [])
plus a b = S (\c - id (\d - if d==0 then []
else id (unS
On Jun 4, 2009, at 11:42 AM, Simon Marlow wrote:
Those two [1..] ring alarm bells. GHC will happily combine them
with CSE and possibly also lift them to the top-level; both
transformations might have a big impact on space behaviour.
Try with -fno-full-laziness and/or -fno-cse.
I did
On Jun 4, 2009, at 2:33 PM, Sebastian Fischer wrote:
Try with -fno-full-laziness and/or -fno-cse.
I did and found no difference when using any or both of these flags.
As int-e pointed out on the ticket that was my fault (spuriously
abstracting from command-line argument order).
On Wed, 2009-06-03 at 15:59 -0400, David Menendez wrote:
On Tue, Jun 2, 2009 at 5:38 AM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
OSX users,
please could you try out Gregory's Haskell Platform package below and
send commentary to the platform list, or file tickets in the platform
On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-Jones wrote:
I'd be quite happy to rename the flag to GeneralisedisedListComp, and
clarify the user manual. Would that suit everyone?
I suppose the alternative is to leave it as TransformListComp, and
document that fact. But I rather agree