> Not sure if this counts as a bug or not, but I've got the following
> program:
>
>
> import GHC.Exts
> import Data.List
>
> wrapper_sum xs = ub_acc_sum xs 0#
> ub_acc_sum :: [Int] -> Int# -> Int
> ub_acc_sum [] v = I# v
> ub_acc_sum ((I# x):xs) v = ub_acc_
Yes, thanks. This is a known bug in 5.04.
What is interesting to me is how many people are using self-recursive
newtypes, with no intervening data types. That is, a type that would be
infinite if the newtype were a type synonym. At least four people have
independently reported the bug, so they
This is the same problem as was causing GHC 5.04 to go into
a loop on FranTk. It's now fixed in the repository and the fix
will be in 5.04.1. Meanwhile use 5.02!
Thanks for the report
Simon
| -Original Message-
| From: Nobuo Yamashita [mailto:[EMAIL PROTECTED]]
| Sent: 16 August 2002
Ahem. Yes, that's a bug all right. How embarassing.
I've fixed it, but won't be able to commit the fix till I get
back at the end of this week. Meanwhile, use 'data' instead of
'newtype' as a workaround.
Thanks for reporting this, and for boiling it down to something small.
Simon
| -O
Just a small note: Changing PP from a datatype renaming (newtype)
to an algebraic datatype (data) or inlining ppThen helps...
Cheers,
S.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haske
Wolfgang Thaller wrote:
> [...]
> There is no problem with ghc-5.02.2 on Intel. I cannot try it out
> on ghc-5.03/intel due to lack of disk space.
>
> Any Ideas?
The GHC from HEAD (Feb 28) crashes, too, even without -O. :-(
No idea why, but -v tells me that it is the first simplifier pas
On Fri, 2 Nov 2001, Simon Peyton-Jones wrote:
> Yes, I agree with this, and I'd already snuck it into the
> rewrite of the Enum section that I had to do anyhow.
>
> Would you like to read the section (6.3.4) and see if
> you think it is better specified now?
>
Yes, it's cool! No objections.
I al
ECTED]]
| Sent: 02 November 2001 15:54
| To: Simon Peyton-Jones
| Cc: Ian Lynagh; [EMAIL PROTECTED]
| Subject: RE: Stack overflow
|
|
| Hi!
|
| OK, so the Int instance for Enum is a bit naughty in that
| [bottom..] is bottom. But then one can argue that all
| instances of Enum should be naughty in
Hi!
OK, so the Int instance for Enum is a bit naughty in that [bottom..] is
bottom. But then one can argue that all instances of Enum should be
naughty in this respect.
The argument is as follows and uses the default declaration of enumFrom in
the Enum class (I've added some types with the intent
The [1..] generates [1,1+1,1+1+1,1+1+1+1, ...]
Those thunks all go into the heap. Then last grabs
the last one and evaluates it, so they all go on the
stack. Result death.
The Int instance for Enum is a bit naughty in GHC:
it is strict. That is [bottom..] is bottom rather than
being [bottom,bo
Christian Lescher wrote:
> [...] I discovered that unpackCStringIO (module CStrings, package lang)
> produces a stack overflow when applied to strings > 65 KB, which seems a
> little strange to me. Is this a bug - or at least a too stack-intensive
> implementation of unpackCStringIO?
A comment f
11 matches
Mail list logo
