RE: problems trying to build GHC 4.08.1
As suggested by the README, I did ./configure --exec-prefix=/home/sml/bin/ia32-linux --enable-hc-boot make boot make and then I get the following error: -- -- ===fptools== Finished making `all' in cbits ... PWD = /n/bopp/shome/sml/Systems/Haskell/GHC/fptools/ghc/lib/std -- -- make[3]: *** No rule to make target `Array.o', needed by `libHSstd.a'. Stop. make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 My machine is running Redhat Linux 6.2 (x86). You probably didn't install the HC files too - there's a pointer from the download page. BTW, it's much simpler (and quicker) to install one of the binary distributions/packages rather than bootstrapping up from .hc files. If you really want to go this way, though, there's a script called hc-build in fptools/distrib that should be of some help. Cheers, Simon
IS THIS A BUG ? rename/RnEnv.lhs:238: Non-exhaustive patterns in function get_tycon_key
Hello, The following code, when compiled with GHC 4.08.1 under an i586 Archictecute with Red Hat Linux 6.2 produces this error message: ERROR MESSAGE: Compilation Dump for: /usr/local/lib/ghc-4.08.1/hsc /tmp/ghc1430.cpp 2 erros -fglasgow-exts -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [ -fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-missing-fields -fwarn-deprecations -fwarn-duplicate-exports -fhi-version=408 -static "-himap=.%.hi:/usr/local/lib/ghc-4.08.1/imports/lang%.hi:/usr/local/lib/ghc-4.08.1/imports/lang%.hi:/usr/local/lib/ghc-4.08.1/imports/std%.hi" "-himap-sep=:" -hifile=/tmp/ghc1430.hi -olang=asm -ofile=/tmp/ghc1430.s -F=/tmp/ghc1430_stb.c -FH=/tmp/ghc1430_stb.h +RTS -H600 -K100 rename/RnEnv.lhs:238: Non-exhaustive patterns in function get_tycon_key == CODE THAT PRODUCES THE ERROR module Foo where import MutableArray import ByteArray import ST import PrelArrExtra class Foo t where foo :: t - ByteArray ix instance Ix ix = Foo (forall s. MutableByteArray s ix) where foo x = runST(unsafeFreezeByteArray x) I think this code is correct (???). The error message suggests a compiler bug. Is this true ? Heron de Carvalho
Help me to correct this code, please ! :-)
Hello, I have tried to compile a code like the following with GHC ... == module Foo where import MutableArray import ByteArray import ST import PrelArrExtra class Foo t where foo :: t - ByteArray ix instance Ix ix = Foo (MutableByteArray s ix) where foo x = runST(unsafeFreezeByteArray x) -- in this context, foo converts a Mutable ByteArray to a ByteArray === ... and the result of the compilation is the following error message : === Compilation Dump for: /usr/local/lib/ghc-4.08.1/hsc /tmp/ghc1047.cpp 2 erros -fglasgow-exts -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [ -fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-missing-fields -fwarn-deprecations -fwarn-duplicate-exports -fhi-version=408 -static "-himap=.%.hi:/usr/local/lib/ghc-4.08.1/imports/lang%.hi:/usr/local/lib/ghc-4.08.1/imports/lang%.hi:/usr/local/lib/ghc-4.08.1/imports/std%.hi" "-himap-sep=:" -hifile=/tmp/ghc1047.hi -olang=asm -ofile=/tmp/ghc1047.s -F=/tmp/ghc1047_stb.c -FH=/tmp/ghc1047_stb.h +RTS -H600 -K100 duvida.hs:15: Inferred type is less polymorphic than expected Quantified type variable `s' escapes It unifies with `s1', which is mentioned in the environment The following variables in the environment mention `s1' x :: MutableByteArray s1 ix Signature type: forall s. ST s a Type to generalise: ST s1 (ByteArray ix) When checking an expression type signature In the first argument of `runST', namely `(unsafeFreezeByteArray x)' In the right-hand side of an equation for `foo': runST (unsafeFreezeByteArray x) Compilation had errors I am trying to find a solution for making possible the "foo" function to convert a MutableByteArray to a ByteArray in this context, but without sucess. How can I avoid this error in this code. Is it possible the foo function to convert a MutableByteArray to a ByteArray in that context ??? I accept suggestions, some explanation about why this code is wrong or some reference that can help me to find a solution ... :-) F. Heron de Carvalho Jr.
Re: negative export list
Zhanyong Wan wrote: I guess the rational behind the current design is that everything by default should be private. However, I doubt whether it is valid: In Haskell the let/where clause allows us to keep auxilliary functions from polluting the top-level name space. As a result, I seldom write "private" functions at top-level, and I think the situation might be true for other functional programmers as well. It isn't true for me. I don't think I would ever use module hiding.
