September 2001 - Nhc-bugs

Segfaults
by Ian Lynagh 30 Sep '01

30 Sep '01

Hi I'm not sure how to simplify this to a simple test case so I've put a complete tarball at http://c93.keble.ox.ac.uk/~ian/igl-0.0.4.tar.gz $ rm -f *.o *.hi Project $ HFLAGS="+RTS -K11048576 -RTS -nkpat" hmake -nhc98 Project nhc98 +RTS -K11048576 -RTS -nkpat -c -o Tokens.o Tokens.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o PCbase.o PCbase.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o PC.o PC.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Parser.o Parser.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Mangle.o Mangle.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o IA.o IA.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Offside.o Offside.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Scanner.o Scanner.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Delit.o Delit.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Args.o Args.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Project.o Project.lhs nhc98 +RTS -K11048576 -RTS -nkpat -o Project PCbase.o IA.o PC.o Parser.o Mangle.o Offside.o Scanner.o Tokens.o Delit.o Args.o Project.o $ cat simple.hs foo = bar $ ./Project < simple.hs Segmentation fault (core dumped) $ Thanks Ian

1 0

nhc installing problems
by Gyun Woo 28 Sep '01

28 Sep '01

Hi, there! On my first trial of installing nhc98 1.08 from sources in my linux machine, I got the following message: > make cd src/compiler98; make fromC make[1]: Entering directory `/home/woogyun/Ftp/nhc98-1.08/src/compiler98' /home/woogyun/Ftp/nhc98-1.08/script//nhc98 -c -d /home/woogyun/Ftp/nhc98-1.08/targets/ix86-Linux/obj/compiler98 *.hc cd /home/woogyun/Ftp/nhc98-1.08/targets/ix86-Linux/obj/compiler98; /home/woogyun/Ftp/nhc98-1.08/script//nhc98 -H8M -o /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/nhc98comp *.o /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/Prelude.a(Show_IOError.o)(.data+0x1d4): undefined reference to `CF_Prelude_46Show_46DErrNo_46ErrNo' /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/Prelude.a(StrError.o)(.data+0x4c): undefined reference to `FN_Prelude_46Enum_46DErrNo_46ErrNo_46fromEnum' /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/Prelude.a(CError.o)(.data+0x38): undefined reference to `FN_Prelude_46Enum_46DErrNo_46ErrNo_46toEnum' collect2: ld returned 1 exit status strip /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/nhc98comp strip: /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/nhc98comp: No such file or directory make[1]: *** [fromC] Error 1 make[1]: Leaving directory `/home/woogyun/Ftp/nhc98-1.08/src/compiler98' make: *** [targets/ix86-Linux/compiler-gcc] 오류 2 The OS configuration is: > uname -a Linux zen 2.2.17-8wl2 #1 Sun Jan 14 22:01:31 KST 2001 i686 unknown Could you help me? Thanks in advance! - Gyun Woo

2 1

Qualified imports
by Ralf Hinze 27 Sep '01

27 Sep '01

In a larger project I use qualified imports a lot. Now, when I try to compile the program with nhc98 I get ... ... nhc98 -98 -I/home/ralf/Haskell/LibRH/nhc98/ -P/home/ralf/Haskell/LibRH/nhc98/ -c -o Future.o Future.lhs Warning: when renaming newtype of imported newtype: Real type of OrdUniqListFM.FM is not visible. I might get boxed/unboxed info wrong. nhc98 -98 -I/home/ralf/Haskell/LibRH/nhc98/ -P/home/ralf/Haskell/LibRH/nhc98/ -c -o LR0.o LR0.lhs ==================================== Error when renaming:: Identifier unionMany defined 3 times. Identifier fromList defined 3 times. Identifier lookup defined 2 times. Identifier union defined 3 times. Identifier elem defined 2 times. Identifier length defined 3 times. This is basically true. However, the definitions reside in different modules that are imported qualified. Unfortunately, I wasn't able to boil down the error (all the toy programs I came up with work fine). I'll send you the files, if you have time to chase down the bug. Cheers, Ralf

2 1

Type synonyms
by Ralf Hinze 26 Sep '01

26 Sep '01

nhc doesn't like the following program ... > type Option = Maybe > f :: Option a -> Maybe a > f = id > main = putStrLn "hello world" Transscript of the session ... >>> nhc98 --version /home/ralf/Lang/bin/nhc98: v1.08 (2001-09-25) [ config: ix86-Linux/ghc by malcolm(a)pc173.cs.york.ac.uk on 25 Sep 2001 ] >>> nhc98 -v Bug.lhs nhc98comp +RTS -RTS -unlit -P/home/ralf/Lang/include/nhc98 ./Bug.lhs ./Bug.lhs /tmp/Bug.12000.hi /tmp/Bug.12000.hc ==================================== Error after type deriving/checking: Type error can not unify Prelude.Maybe with 1 and 0 arguments when binding final type to function at 4:8. The problem disappears if we change the type definition to > type Option a = Maybe a Cheers, Ralf

2 1

nhc98 module bug
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

The following combination of three modules breaks nhc98 v1.08: ===== First module ====== module M (T, foo) where newtype T = T Int foo :: Int -> T foo x = T (x + 1) ===== Second module ====== module N (foo) where import M (T) import qualified M (foo) data S = S T foo :: Int -> S foo y = S $ M.foo y ===== Third module ====== import N (foo) main = print $ const 42 (foo 100) ========================= Compile with nhc98 -c M.hs nhc98 -c N.hs nhc98 -c Main.hs to get Error when renaming:: Identifier foo defined 2 times. The problem is quite subtle. It is the combination of qualified import of `M.foo' in `N' and export of another `foo' in `N', where `N.foo' has a type that depends on `M.T'. Looking into `N.hi' there are indeed two definitions of `foo', where nhc doesn't seem to properly distinguish that they come from two different modules. Cheers, Manuel PS: In case anybody is wondering, I am still trying to get nhc to compile the basic compiler-support libraries that I need to port C->Haskell.

2 3

hmake stdout/stderr confusion
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

[I hope, this is the right place to report hmake problems.] When hmake emits the message Stop - hmake dependency error. it does so to stdout. I think, it should go to stderr, as the current behaviour in combination with output redirection can be surprising. Cheers, Manuel

2 2

NHC 1.08 & gmp
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

Compiling nhc 1.08 on a RedHat 7.1 machine, I get hmake -nhc98 -K10M +CTS -H20M -CTS Hatobserve /home/chak/sandbox/src/nhc98-1.08/targets/ix86-Linux/obj/hat/hatlib.a -d/home/chak/sandbox/src/nhc98-1.08/lib/ix86-Linux make[1]: hmake: Command not found make[1]: *** [/home/chak/sandbox/src/nhc98-1.08/lib/ix86-Linux/hat-observe] Error 127 make[1]: Leaving directory `/home/chak/sandbox/src/nhc98-1.08/src/tracer/hat' make: *** [lib/ix86-Linux/hat-stack] Error 2 It seems as if the path to `hmake' got lost somewhere. I worked around it by doing a `make install' at this point followed by another `make' (and another `make install'). Cheers, Manuel [1] You need gmp-devel to compile programs using gmp, as opposed to running programs that have been dynamically linked against gmp.

2 2

deriving Ix
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

The program import Ix newtype Name = Name Int deriving (Eq, Ord, Ix) main = print 42 gives me Error when renaming:: Identifier Ix._tupleRange used at 4:33 is not defined. Identifier Ix.inRange used at 4:33 is not defined. Identifier Ix.range used at 4:33 is not defined. Type class Ix.Ix used at 4:33 is not defined. Identifier Ix._tupleIndex used at 4:33 is not defined. Identifier Ix.index used at 4:33 is not defined. which IMO contradicts the definition of the Standard Libraries. Manuel

2 1

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