- Nhc-bugs - Haskell.org

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> > Then I think hugs and nhc98 are wrong. The report states that the > > unliterate version of the file is recovered by "taking only > those lines > > beginning with '>', and removing the first character of > those lines", > > which would leave the lines indented by a single space, not two. > > This would appear to be an un-remarked change to the Report since > version 1.2. That version states that "program lines have the > leading '>' replaced by a leading space, to preserve tab alignments". > Version 1.3 removed this specification, and the changed specification > only appeared in Haskell'98. > > I would like to submit it as a bug in the Report - the older > specification, as implemented by Hugs and nhc98 makes more sense in > conjunction with the layout rule. I'm inclined to agree. But I'd like to know what the reason for the change in the first place was. GHC's unlit preprocessor converts the tabs to spaces in such a way that they line up after removal of the '>' characters, by the way. Cheers, Simon

1 0

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> The definitions of foo and bar are not at the same indentation level, > so they are being rejected by the layout rule. At least, hugs and > nhc98 accept it if you indent bar by two spaces, ghc still complains: > > ghc -c lit.lhs > lit.lhs:9: parse error on input `_' Then I think hugs and nhc98 are wrong. The report states that the unliterate version of the file is recovered by "taking only those lines beginning with '>', and removing the first character of those lines", which would leave the lines indented by a single space, not two. Cheers, Simon

2 1

Literate scripts not handled correctly
by Ian Lynagh 18 Sep '01

18 Sep '01

Hi all My understanding is that the following script: ----- cut here ----- > foo :: Int -> Int > foo _ = 2 \begin{code} bar :: Int -> Int bar _ = 1 \end{code} ----- cut here ----- should be valid and define foo and bar (although the report does say "It is not advisable to mix these two styles in the same file"). However, in hugs: ERROR Q.lhs:7 - Syntax error in input (unexpected symbol "bar") % ghc -c -o Q.o Q.lhs Q.lhs:7: parse error on input `bar' % nhc98 -c -o Q.o Q.lhs In file ./Q.lhs: 7:1 Found bar but expected a {-EOF-} Secondly, in the following script (which I think should define main according to the report): ----- cut here ----- \begin{code} module Main where main :: IO() main = putStrLn "Foo" \end{code} ----- cut here ----- hugs: ERROR W.lhs:12 - Empty script - perhaps you forgot the `>'s? % nhc98 -c -o W.o W.lhs Warning: Can not find main in module Main. ghc -c -o W.o W.lhs W.lhs line 11: unlit: missing \end{code} Interestingly it works in GHC if you remove the white space before the end but not before the begin. Thanks Ian

2 1

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> My understanding is that the following script: > > ----- cut here ----- > > > foo :: Int -> Int > > foo _ = 2 > > \begin{code} > > bar :: Int -> Int > bar _ = 1 > > \end{code} > > ----- cut here ----- > > should be valid and define foo and bar (although the report > does say "It > is not advisable to mix these two styles in the same file"). > > However, in hugs: > ERROR Q.lhs:7 - Syntax error in input (unexpected symbol "bar") This is probably due to layout. The unliterate version of the file would be foo :: Int -> Int foo _ = 2 bar :: Int -> Int bar _ = 1 so the occurrence of the token 'bar' at a column less than that of the first 'foo' causes a close brace to be inserted by the layout system, closing the top-level declaration group. > Secondly, in the following script (which I think should define main > according to the report): > > ----- cut here ----- > > \begin{code} > > module Main where > > main :: IO() > main = putStrLn "Foo" > > \end{code} > > ----- cut here ----- > > hugs: > ERROR W.lhs:12 - Empty script - perhaps you forgot the `>'s? > > % nhc98 -c -o W.o W.lhs > Warning: Can not find main in module Main. > > ghc -c -o W.o W.lhs > W.lhs line 11: unlit: missing \end{code} > > Interestingly it works in GHC if you remove the white space before the > end but not before the begin. Yes, it looks like GHC's unlit program removes whitespace when looking for \begin{code}, but not for \end{code}. The report isn't explicit about whether whitespace is allowed on these lines, but I would tend to the view that it isn't. Cheers, Simon

1 0

Type error type clash between Prelude.SR and Prelude.R
by Ian Lynagh 17 Sep '01

17 Sep '01

Not sure if this is related to my previous mail about negate, but that got in the way when I was trying to work out what was going on. nhc98 -T +RTS -K11048576 -RTS -c -o Mangle.T.o Mangle.lhs ==================================== Error after type deriving/checking: Type error type clash between Prelude.SR and Prelude.R when trying to apply function at 68:28 to its 1:st argument at 68:29. Type error type clash between Prelude.SR and Prelude.R when trying to apply function at 65:28 to its 1:st argument at 65:29. Lines 64 to 58 of Mangle.lhs are > -- If there is a digit then grab it > get_infixes m (Just (it, -1)) (Number ([c]):ts) > = get_infixes m (Just (it, ord c - ord '0')) ts > -- Otherwise default to 9 > get_infixes m (Just (it, -1)) ts = get_infixes m (Just (it, 9)) ts I can put the whole file somewhere if you need it. Thanks Ian

2 2

Re: [nhc-bugs] PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base'
by malcolm＠cs.york.ac.uk 17 Sep '01

17 Sep '01

> PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base' > PC_base.z.o(.data+0x3c): undefined reference to `TMSUB_PC_95base' I suspect this is a fault in the name-mangling part of our time profiler. Try renaming the module so that it does not have an underscore in it! (both the filename and the module name I guess.) Regards, Malcolm

2 1

negate problems?
by Ian Lynagh 17 Sep '01

17 Sep '01

Various small changes work, but this doesn't: > module Main where > main :: IO() > main = putStrLn $ show $ foo 1 > foo :: Int -> Int > foo (-1) = 6 > foo i = i Compiling it gives nhc98 -c -o Q.o Q.lhs ==================================== Error when renaming:: Unbound Identifier - at 8:8 [Leaf2 ((Prelude._x,Identifier),160) followed by more stuff that I can give you if you need it and can't reproduce the problem. Thanks Ian, on a roll tonight...

2 1

PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base'
by Ian Lynagh 14 Sep '01

14 Sep '01

Hi again... What is the cause of these errors? Without -t it compiles fine, as does a tiny test program with -t. I can make the source available if needed, but it is large and I suspect I'm doing something silly. HFLAGS="+RTS -K11048576 -RTS -nkpat" hmake -t -nhc98 main nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Tokens.z.o Tokens.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o PC_base.z.o PC_base.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o PC.z.o PC.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Parser.z.o Parser.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Mangle.z.o Mangle.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Offside.z.o Offside.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Scanner.z.o Scanner.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Args.z.o Args.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o main.z.o main.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -o main PC_base.z.o PC.z.o Parser.z.o Mangle.z.o Offside.z.o Scanner.z.o Tokens.z.o Args.z.o main.z.o PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x3c): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0xa0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0xd0): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x124): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x158): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x1b0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x1e4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x240): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x274): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x2c8): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x304): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x390): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x3c4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x424): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x458): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x4f0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x524): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x5b4): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x5e4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x618): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x64c): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x688): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x6bc): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x75c): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x788): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x7b4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x7e0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x814): undefined reference to `TMSUB_PC_95base' collect2: ld returned 1 exit status Thanks Ian

1 0

Bug in pattern matching with nkpat
by Ian Lynagh 14 Sep '01

14 Sep '01

Hi all With the following code nhc98 prints 7, not 6 as I'd expect (and hugs does). module Main where data Wibble = Foo | Bar main :: IO() main = putStrLn $ show $ foo 1 Bar foo :: Int -> Wibble -> Int foo (n+1) Foo = 5 foo (n+1) Bar = 6 foo _ _ = 7 Thanks Ian

2 2

Renaming bug?
by Mark Tehver 17 Aug '01

17 Aug '01

Hi, I am resending the following bug report. It was first reported under NHC 1.02 but seems to be still present in NHC 1.06. I got following error: ==================================== Error when renaming:: Unbound Identifier a0 at 4:44 ... (lots of internal compiler state lines) under NHC 1.02 cygwin (win2k), although I think the program that caused this is correct. The program consists of 2 small files: File Test1.hs: --- module Test1(fn) where import Test2 fn :: Test -> Int fn t@(Test { a0 = a } ) = a0 t + a --- File Test2.hs: --- module Test2(Test(..)) where data Test = Test { a0 :: Int, b0 :: Int } -- I compiled Test2.hs with "nhc98 -c Test2.hs" and then tried to compile Test1.hs and got this error. Best regards, Mark

2 1