of partition. You might
write code that depends on the lazy behaviour, and such code wouldn't
work with earlier patchlevels.
Yes, the no change to library APIs policy is quite restrictive. It
was introduced as a way to try to provide stability between releases -
we provide bugfixes without breaking
not been released so far ...
On Thu, Oct 14, 2004 at 12:02:20PM +0200, Josef Svenningsson wrote:
A little browsing in the CVS reveals that partition is fixed in GHC's
libraries but that it was done after the 6.2 branch. So the 6.2
branch is still using the old erroneous definition.
Could
it?
For 6.2.2 is have not been released so far ...
On Thu, Oct 14, 2004 at 12:02:20PM +0200, Josef Svenningsson wrote:
A little browsing in the CVS reveals that partition is fixed in GHC's
libraries but that it was done after the 6.2 branch. So the 6.2
branch is still using the old
Dear GHC developers,
the function let ns = [1 .. 10^6] :: [Int]
p = partition even ns
in
take 2 $ fst p
computes too long in ghc-6.2.2-September-26
and needs several megabyte of stack.
What might be the reason
the function let ns = [1 .. 10^6] :: [Int]
p = partition even ns
in
take 2 $ fst p
computes too long in ghc-6.2.2-September-26
and needs several megabyte of stack.
this has been noticed a few times, for example
http://www.mail
A little browsing in the CVS reveals that partition is fixed in GHC's
libraries but that it was done after the 6.2 branch. So the 6.2 branch is
still using the old erroneous definition.
Could this fix be merged into the 6.2 branch, please?
/Josef
-Original Message-
From
Indeed, could it?
For 6.2.2 is have not been released so far ...
On Thu, Oct 14, 2004 at 12:02:20PM +0200, Josef Svenningsson wrote:
A little browsing in the CVS reveals that partition is fixed in GHC's
libraries but that it was done after the 6.2 branch. So the 6.2 branch is
still using
