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
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
fromEn
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 = Re
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
#808: Move the GHC Commentary to the wiki
--+-
Reporter: simonmar |Owner:
Type: task | Status: new
Priority: normal |Milestone:
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
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 i
