Custom Query (7507 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (4 - 6 of 7507)

1 2 3 4 5 6 7 8 9 10 11 12
Ticket Resolution Summary Owner Reporter
#125 fixed GHCi Usability nobody nobody
Description
About GHCi

I find that Haskell interpreter is rather difficult to use:
1."f=3" is a legal statement in Haskell, i.e. define "f" as 
a 
   constant function, but a parse error occurs.
  "let f=3" is illegal, "let" and "in" are used together, but
   it works in GHCi. 
2. if I happen to print out an infinite list, I don't know how 
   to interrupt it, when press Ctrl+C, GHCi just quit.
3. I can't use "import" to import modules. There are 
many sub 
   directories in the imports directory, but I don't know 
how to 
   import libraries in concurrent, win32, util, lang and 
objectio
#179 fixed Instance match failure on openTypeKind simonpj simonpj
Description
Consider

    instance Show (a->b) where ...

    foo x = show (\ _ -> True)

This fails with:
    No instance for (Show (t -> Bool))
      arising from use of `show' at Foo.hs:5


Reason: the type of (\_ -> True) is  (t -> Bool) where
t has an "openTypeKind".  It's possible that the function 
will be applied to say an Int#, and the openTypeKind 
records that this is OK.

BUT, the instance decl Show (a->b) has 
a::liftedTypeKind, and that doesn't match an 
openTypeKind type variable.


This bug relates to GHC's unsatisfactory treatment of 
the variants of kind "type", for which there are at least 2 
other SourceForge bugs registered (753780 and  
753777).  It's very obscure, so I'm not going to fix it 
today.
#186 fixed Bad sparc Int64 code via NCG with -O benl nobody
Description
On sparc machines ( sparc-sun-solaris2.6,
sparc-unknown-openbsd ) testsuite tests exercising
Int64 code are broken when compiled the optasm way.
This includes the arith011 test and the enum02 test,
possibly others. Trivial Int64 code will produce
erroneous results. Turning off optimisation, or
compiling via C, will generate correct code. 

Some examples.. 

This one comes from enum02:

  import Int
  main = do print $ pred (1 :: Int64)

$ ./a.out 
  4294967295

which is UINT_MAX...
And from arith011, this generates incorrect results:

  import Int
  main = do print $ take 10 [ (0::Int64), toEnum 2 .. ]

on x86:
   [0,2,4]
on sparc:
   [0,8589934592,17179869184]

which is 2 * (UNIT_MAX + 1), and then twice that.
This erroneously generates an infinte sequence, filling
up /usr on my system before I realised what happened:

  import Int
  main = do print [ (0::Int64) .. toEnum 2 ]

-- Don Stewart
1 2 3 4 5 6 7 8 9 10 11 12
Note: See TracQuery for help on using queries.