Re: GHC 6.2.2 and 6.4.1 on IRIX64 both failed, this time with new error
simonmarhaskell: -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o Cmm lint error: in proc stg_ap_0_ret in basic block c2 in assignment: R1 = I32[R1 + 8 + 0]; This looks like an inconsistency in bit widths somewhere: GHC thinks the width of a word is 64, but soemthing else thinks its 32 bits. I suspect ghc/includes/DerivedConstants.h doesn't agree with ghc/includes/ghcautoconf.h. Perhaps you're not passing -mabi when compiling ghc/includes/mkDerivedConstants.h? Yes, when hacking on irix/mips64, I needed: export LDFLAGS=-L/usr/freeware/lib64 -L/import/pill0/1/dons/lib -mabi=64 export CPPFLAGS=-I/usr/freeware/include -I/import/pill0/1/dons/include export CFLAGS=-mabi=64 export GHCRTS=-K20m export LD=/usr/bin/ld -64 cat mk/build.mk END SRC_CC_OPTS+=-mabi=64 SRC_HC_OPTS+=-optc-mabi=64 -opta-mabi=64 -optl-mabi=64 SRC_CC_OPTS+=-L/usr/freeware/lib64 -L/import/pill0/1/dons/lib SRC_HC_OPTS+=-L/usr/freeware/lib64 -L/import/pill0/1/dons/lib END And you'll need to add them to the final compiler's package.conf ldOptions as well. Btw, Andrew, did you try the ghc 6.0.1 Irix/mips64 binary on haskell.org/ghc? -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
arithmetic sequences and the prelude: minor problems?
Hi, Haskell Report 6.3.4, pg 86-87, talks about arithmetic sequences. For all four of these Prelude numeric types, all of the enumFrom family of functions are strict in all their arguments. This seems to imply that for other Prelude types, functions of the enumFrom family aren't. Yet, bot :: Bool - Bool bot x = bot x take 1 [False .. bot True] doesn't terminate. Possible solution, rewording: For all Prelude types, all of the enumFrom family of functions are strict in all their arguments. Incidentally, [1..5] is accepted (no space between 1 and the dots), while [False..True] is not (no spaces after False), which appears to be a parsing inconsistency. All this with, ghc-6.4.2 recent snapshots (and also in 6.4). As for the upper limit, spaces or not are both OK. Share and enjoy. Laszlo ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #808: Move the GHC Commentary to the wiki
#808: Move the GHC Commentary to the wiki --+- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal |Milestone: Component: Documentation | Version: 6.4.1 Severity: normal | Keywords: Os: Unknown| Difficulty: Moderate (1 day) Architecture: Unknown| --+- There's a bunch of invaluable documentation on the innards of GHC in the [http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ Commentary]. However, it isn't easy to edit: the commentary is in HTML checked into the darcs repository. It would be better if this material was on the wiki, so we can have all the developer docs in one place. This does mean converting the HTML into wiki, so probably an script of some kind would be the easiest way to do it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/808 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: arithmetic sequences and the prelude: minor problems?
Laszlo Nemeth wrote: Incidentally, [1..5] is accepted (no space between 1 and the dots), while [False..True] is not (no spaces after False), which appears to be a parsing inconsistency. It's a bug, but a known one (we have a test in the test suite for it). Hugs has the same bug, so at least there's some consistency across implementations. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
unexpected arithmetic sequence and deriving Enum behaviour
Hi,
Consider the following code fragment:
data Colour = Red | Black | Blue deriving (Show, Bounded)
instance Enum Colour where
succ Red = Black
succ Black = Blue
succ Blue = error succ of maxBound
fromEnum Red = 1
fromEnum Black = 2
fromEnum Blue = 3
toEnum 1 = Red
toEnum 2 = Black
toEnum 3 = Blue
toEnum n = error (? ++show n)
main = do print $ [Red ..]
Notice that there is no deriving Enum (which would be an error according
to the Report) and there is no definition for 'enumFrom'.
So, in the first place I'd expect a warning for main for the use of the
arithmetic sequence, something about a missing definition. There isn't
one, and the program compiles. Interestingly, -ddump-deriv doesn't show
anything about deriving instances for Colour, yet, obviously something
gets derived.
When you run it, it dies with an error message from 'toEnum n' (or
non-exhaustive pattern if you leave that one out). Looking at core
reveals the reason for this:
Main.lvl7 :: GHC.Base.Int - [Main.Colour] - [Main.Colour]
[GlobalId]
[Arity 2]
Main.lvl7 = \ (x1 :: GHC.Base.Int) (ys :: [Main.Colour]) -
GHC.Base.: @ Main.Colour (Main.toEnum x1) ys
Main.lvl8 :: [Main.Colour]
[GlobalId]
[]
Main.lvl8 = GHC.Enum.eftIntFB
@ [Main.Colour] Main.lvl7 (GHC.Base.[] @ Main.Colour) 1
2147483647
Main.lvl9 :: [Main.Colour]
[GlobalId]
[]
Main.lvl9 = GHC.Enum.eftIntFB
@ [Main.Colour] Main.lvl7 (GHC.Base.[] @ Main.Colour) 2
2147483647
Main.lvl10 :: [Main.Colour]
[GlobalId]
[]
Main.lvl10 = GHC.Enum.eftIntFB
@ [Main.Colour] Main.lvl7 (GHC.Base.[] @ Main.Colour) 3
2147483647
Main.$dmenumFrom :: Main.Colour - [Main.Colour]
[GlobalId]
[Arity 1
Str: DmdType S]
Main.$dmenumFrom = \ (w :: Main.Colour) -
case [Main.Colour] w of wild {
Main.Red - Main.lvl8; Main.Black - Main.lvl9;
Main.Blue - Main.lvl10
}
The max bound which gets used is the one for Int, not for Colour!
Perhaps this isn't a bug, but definitely an undocumented and rather
unexpected 'feature'. This is with ghc-6.4 onwards, and I haven't
checked earlier versions.
Share and enjoy.
Laszlo
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: unexpected arithmetic sequence and deriving Enum behaviour
Hi Laszlo, Laszlo Nemeth wrote: Consider the following code fragment: data Colour = Red | Black | Blue deriving (Show, Bounded) instance Enum Colour where succ Red = Black succ Black = Blue succ Blue = error succ of maxBound fromEnum Red = 1 fromEnum Black = 2 fromEnum Blue = 3 toEnum 1 = Red toEnum 2 = Black toEnum 3 = Blue toEnum n = error (? ++show n) main = do print $ [Red ..] Notice that there is no deriving Enum (which would be an error according to the Report) Why do you say that? Can you give a pointer to the relevant text in the report? I can't see anything wrong here. The minimal complete instance of Enum consists of toEnum and fromEnum, which yours does. and there is no definition for 'enumFrom'. So, in the first place I'd expect a warning for main for the use of the arithmetic sequence, something about a missing definition. There isn't one, and the program compiles. Interestingly, -ddump-deriv doesn't show anything about deriving instances for Colour, yet, obviously something gets derived. When you run it, it dies with an error message from 'toEnum n' (or non-exhaustive pattern if you leave that one out). Looking at core reveals the reason for this: [ core snipped ] The max bound which gets used is the one for Int, not for Colour! This is because, as per the report, GHC defines the default method for enumFrom as: enumFrom x = map toEnum [fromEnum x ..] the sequence on the RHS is at type Int, and hence doesn't terminate until it reaches maxBound::Int. Perhaps you expect that, because your type is also an instance of Bounded, that enumFrom should behave differently. However, there can only be one default method for enumFrom. Perhaps this isn't a bug, but definitely an undocumented and rather unexpected 'feature'. This is with ghc-6.4 onwards, and I haven't checked earlier versions. You're right, I don't think it's a bug. Also, if you had derived Enum instead of defining it, you would have got a version that behaved in the expected way. You defined an instance of Enum yourself, and got exactly what you asked for! Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: unexpected arithmetic sequence and deriving Enum behaviour
Simon, Laszlo presented some code: Consider the following code fragment: data Colour = Red | Black | Blue deriving (Show, Bounded) instance Enum Colour where ... and then remarked: Notice that there is no deriving Enum (which would be an error according to the Report) You asked: Why do you say that? Can you give a pointer to the relevant text in the report? I can't see anything wrong here. I think he was referring to the fact that it is illegal to both *derive* and *define* an instance of a particular class for a type. Regards, Stefan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
