November 2000 - Glasgow-haskell-users

RE: types from ghc (another question)
by Simon Peyton-Jones 20 Nov '00

20 Nov '00

Bernie All (I think) the top level bindings come out of the type check as an AbsBinds. This is where we generalise from a monomorphic thing to a polymorphic thing. An AbsBinds has four components, the third of which is a list of triples (TyVar, Id, Id). You want to grab the first of these Ids (only). You can then ignore the MonoBinds inside the fourth component of the AbsBinds. So your code will get quite a bit simpler. The two Ids in the triple are the polymorphic top-level binder and the monomorphic (perhaps recursive) thing that it generalises. It's a bit hard to explain in a short space. Look at the output of the desugarer for a simple defn, to see what an AbsBinds translates to. Anyway these polymorphic Ids will have exactly the for-alls and constraints that you want hope this gets you moving Simon | -----Original Message----- | From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU] | Sent: 19 November 2000 07:34 | To: glasgow-haskell-users(a)haskell.org | Cc: bjpop(a)cs.mu.OZ.AU | Subject: types from ghc (another question) | | | Hi again, | | Simon Peyton-Jones writes: | | > Don't try to get the type environment out. Instead, look at the | > syntax tree produced by the type checker. Each binder is an Id. | > There's a function | > idType :: Id -> Type | > that tells you the type of each binder. Quite how you present it | > to the user in a good way isn't clear to me, | | Thanks Simon. | | In TcModule.lhs I added some code like this: | | myDumpTc results | = myPprMonoBinds $ tc_binds results | where | myPprMonoBinds (AndMonoBinds b1 b2) | = myPprMonoBinds b1 $$ myPprMonoBinds b2 | | myPprMonoBinds (FunMonoBind id _ matches _) | = (ppr (toRdrName id)) <+> | dcolon <+> | (ppr $ idType id) $$ | myPprMatches matches | | {- etc, etc ... -} | | | For the following contrived example: | | main = putStr $ show (fred 1 3) | where | fred a b = let myid x = x in myid (plus a b) | plus x y = x + y | | My output is: | | main :: IO () | plus :: a -> a -> a | fred :: a -> a -> a | myid :: t_aMv -> t_aMv | | Which is nearly exactly what I want, however, the class | constraints are missing | from the signatures for plus and fred. The universal | quantification of | the type variable t_aMv is also missing. | | One curiosity is that the compiler has generated the variable 'a' in | the two circumstances where the variables are constrained, | which makes me think | something special is happening here. | | If you defined all the binders at the top-level and supplied the | -ddump-types flag to ghc (with a modification to the code to | turn off the | conversion to HsType, so that the unique variable names do | not get clobbered) | you get the proper polymorphic type signatures | for each of the identifiers (ie myid :: forall t_aMv . t_aMv | -> t_aMv). | | My question is: can I find out any information about the | constraints on | variables from the types that I find in the tc_binds | component of the type | checking results? | | (apologies for my being long-winded). | | Regards, | Bernie. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

types from ghc (another question)
by Bernard James POPE 19 Nov '00

19 Nov '00

Hi again, Simon Peyton-Jones writes: > Don't try to get the type environment out. Instead, look at the > syntax tree produced by the type checker. Each binder is an Id. > There's a function > idType :: Id -> Type > that tells you the type of each binder. Quite how you present it > to the user in a good way isn't clear to me, Thanks Simon. In TcModule.lhs I added some code like this: myDumpTc results = myPprMonoBinds $ tc_binds results where myPprMonoBinds (AndMonoBinds b1 b2) = myPprMonoBinds b1 $$ myPprMonoBinds b2 myPprMonoBinds (FunMonoBind id _ matches _) = (ppr (toRdrName id)) <+> dcolon <+> (ppr $ idType id) $$ myPprMatches matches {- etc, etc ... -} For the following contrived example: main = putStr $ show (fred 1 3) where fred a b = let myid x = x in myid (plus a b) plus x y = x + y My output is: main :: IO () plus :: a -> a -> a fred :: a -> a -> a myid :: t_aMv -> t_aMv Which is nearly exactly what I want, however, the class constraints are missing from the signatures for plus and fred. The universal quantification of the type variable t_aMv is also missing. One curiosity is that the compiler has generated the variable 'a' in the two circumstances where the variables are constrained, which makes me think something special is happening here. If you defined all the binders at the top-level and supplied the -ddump-types flag to ghc (with a modification to the code to turn off the conversion to HsType, so that the unique variable names do not get clobbered) you get the proper polymorphic type signatures for each of the identifiers (ie myid :: forall t_aMv . t_aMv -> t_aMv). My question is: can I find out any information about the constraints on variables from the types that I find in the tc_binds component of the type checking results? (apologies for my being long-winded). Regards, Bernie.

1 0

RE: Instant readFile
by Simon Marlow 16 Nov '00

16 Nov '00

George Russell writes: > The > readFile :: FilePath -> IO String > action returns the contents of the associated file. This is > almost what > I want, but not quite, because readFile is lazy. Hence if > the string is > only partly read, the file is still open. What I want > instead is a function > which > (a) opens the file; > (b) slurps the complete contents compactly into an array; > (c) closes the file; > (d) makes the contents of the array available as a String. > So instead I wrote the following: > > copyFileToString :: FilePath -> IO String > copyFileToString file = > do > (addr,len) <- IOExts.slurpFile file > CString.unpackCStringLenIO addr len > > However on further consideration this also seems to me to be > unsatisfactory, > because although I don't understand this issue very well, I > don't think > the (addr) address containing the complete file contents will ever get > deallocated, because there's no way the GC can know that this > particular > Addr can be free'd. (Is that correct?) So please, how > _should_ I write this > function? Well, you could always free the address directly after unpacking it, since unpackCStringLenIO generates the whole string in one go. > It all is a bit of a mystery to me how you are supposed to > use Addr like things > without space leaks. A little more explanation in the > documentation would not > perhaps be amiss . . . The alternative is to use a ByteArray to store the string. These live in the heap and so get garbage collected automatically, and should be quicker to allocate than using malloc. Check out the hGetBuf family of functions in IOExts, there are versions for reading into/out of ByteArrays, and there are variants of unpackCString that work with ByteArrays (unpackNBytesBA, for example). [ side note: ByteArrays and MutableByteArrays will eventually be replaced by UArray and STUArray/IOUArray which are functionally identical but have a nice overloaded interface in IArray/MArray. ] Cheers, Simon

1 0

RE: Problems with libgmp
by Simon Marlow 16 Nov '00

16 Nov '00

> > > So, I can't quite work out what went wrong in your case. > If the build > > > didn't detect GMP 2, then it should have just used the > one in the tree. > > > > Obviously, when linking, it did not use the one in the tree :-( > > Conclusion: The Linux linker does not behave like other linkers or > > there is a bug in some Makefile. > > Of late I have had problems with libgmp2 and woody-debian. I > solved the > problem the first time around by adding a sym link > /usr/lib/libgmp2.so -> > /usr/lib/libgmp.so.2.0.2 > > Yesterday I solved the problem by installing libgmp2-dev > because ld was > looking for libgmp.a for some reason when trying to compile hdirect. > > Hacks at best. Haven't really looked for whys and wherefores. The binary distributions of 4.08.2 will come with a statically linked libgmp.a. It's up to the package maintainers (RedHat RPM, Debian etc.) to decide the best approach for those systems, i.e. whether it's better to depend on the system-supplied shared libgmp or supply one in the GHC package. On FreeBSD for example I just use the system-supplied one since it's part of the base system. Cheers, Simon

1 0

RE: Problems with libgmp
by Simon Marlow 15 Nov '00

15 Nov '00

> I am maintaining the Haskell stuff at informatik.uni-muenchen.de. > (I took over the job from Sven Panne.) > > As a first exercise, I try to compile ghc-4.08.1 from scratch. > But I always run into trouble with the libgmp stuff. > IMHO, my problems are caused by several factors: > > 1. We use Suse Linux 7.0 (that provides libgmp-3.0.x). > 2. The ghc-4.08-1 distribution includes libgmp-2.x.x. > 3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names > are generated only if the header file is included. > 4. The configure script does not recognize that libgmp is > installed (because it does not include the header file.) > 5. When linking, the linker cannot resolve symbols prefixed by mpz_ > (because the 2.x.x header file was used in compilation but the > linker uses the shared library provided by Suse Linux.) > 5. Even if informed about the local installation of libgmp > (by manually > changing config.cache), the 2.x.x header file will be used (again > resulting in unresolved bindings when linking). > > The same problems occur when bootstrapping from .hc files. > > What to do? Should I hack the Makefiles? Should I replace the libgmp > distribution included in the ghc distribution by some new 3.x.x > distribution? I'll try to clarify the situation, since it's a bit confusing. - GHC tries to detect GMP 2 on the host system during the configuration process. If it detects it, the build will go on to use the installed version. - If GMP 2 was *not* found, then we fall back to the copy of GMP in the source tree, which is build statically. - the RPMs have a dependency on the gmp2 packages. - GMP 3 is only source compatible with GMP 2, as you discovered. Furthermore, using the GMP 2 headers with the GMP 3 library aint gonna work. (if your system is set up like this, then it's broken, just like ours :-) - GHC versions post-4.08.X use GMP 3. So, I can't quite work out what went wrong in your case. If the build didn't detect GMP 2, then it should have just used the one in the tree. BTW, you can't use GMP 3 with ghc-4.08.1 (the native code generator at least will break). Hope this helps :) Cheers, Simon

3 2

Instant readFile
by George Russell 15 Nov '00

15 Nov '00

The readFile :: FilePath -> IO String action returns the contents of the associated file. This is almost what I want, but not quite, because readFile is lazy. Hence if the string is only partly read, the file is still open. What I want instead is a function which (a) opens the file; (b) slurps the complete contents compactly into an array; (c) closes the file; (d) makes the contents of the array available as a String. So instead I wrote the following: copyFileToString :: FilePath -> IO String copyFileToString file = do (addr,len) <- IOExts.slurpFile file CString.unpackCStringLenIO addr len However on further consideration this also seems to me to be unsatisfactory, because although I don't understand this issue very well, I don't think the (addr) address containing the complete file contents will ever get deallocated, because there's no way the GC can know that this particular Addr can be free'd. (Is that correct?) So please, how _should_ I write this function? For example, I could try and wrap the addr into a ForeignObj, but then how would I ensure that when the String gets gc'd, the ForeignObj does too? It all is a bit of a mystery to me how you are supposed to use Addr like things without space leaks. A little more explanation in the documentation would not perhaps be amiss . . .

2 1

The Parsec library distributed with GHC
by José Romildo Malaquias 15 Nov '00

15 Nov '00

Hello. The Parsec library (in package text from hslibs) distributed with GHC 4.08.1 and from CVS does not work as expected. When I try the attached program, ghc gives me error messages: ================================= test.hs:6: Couldn't match `TokenParser' against `[Char]' Expected type: TokenParser Inferred type: [Char] In the first argument of `symbol', namely `"let"' In a do statement: symbol "let" test.hs:12: Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at test.hs:12 In the right-hand side of an equation for `main': print (parse pLet "" "let a = 232") Compilation had errors ================================= This same program works if I use the Parsec library downloaded from the author page <http://www.cs.uu.nl/~daan> (after correcting a small bug relative to using some names from the Char module without importing them). I hope the library gets updated in the GHC CVS repository and the next GHC release corrects this problem. Regards, Romildo -- Prof. José Romildo Malaquias <romildo(a)iceb.ufop.br> Departamento de Computação Universidade Federal de Ouro Preto Brasil

1 0

Problems with libgmp
by Michael Marte 14 Nov '00

14 Nov '00

Hello, I am maintaining the Haskell stuff at informatik.uni-muenchen.de. (I took over the job from Sven Panne.) As a first exercise, I try to compile ghc-4.08.1 from scratch. But I always run into trouble with the libgmp stuff. IMHO, my problems are caused by several factors: 1. We use Suse Linux 7.0 (that provides libgmp-3.0.x). 2. The ghc-4.08-1 distribution includes libgmp-2.x.x. 3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names are generated only if the header file is included. 4. The configure script does not recognize that libgmp is installed (because it does not include the header file.) 5. When linking, the linker cannot resolve symbols prefixed by mpz_ (because the 2.x.x header file was used in compilation but the linker uses the shared library provided by Suse Linux.) 5. Even if informed about the local installation of libgmp (by manually changing config.cache), the 2.x.x header file will be used (again resulting in unresolved bindings when linking). The same problems occur when bootstrapping from .hc files. What to do? Should I hack the Makefiles? Should I replace the libgmp distribution included in the ghc distribution by some new 3.x.x distribution? Thank you, Michael Marte

1 0

Re: Bug in GHC's Garbage Collection? (fwd) - C Strings
by Christian Lescher 13 Nov '00

13 Nov '00

Hi Simon, > > 1) How to convert the Haskell string to a C string? - There's > > a function > > > > packCString# :: [Char] -> ByteArray# > > packCString# str = case (packString str) of { ByteArray _ _ bytes -> > > bytes } > > > > in CStrings.lhs / PrelPack.lhs, which I probably have to use. > > Yes (but use packString rather than packString#). Okay, so I have use: packString :: [Char] -> ByteArray Int btw: what's the difference between packString and packCString then? > > 2) How to pass a pointer (Addr) of the converted string back > > to the outside > > world? > > You can pass the ByteArray directly to a foreign imported function (which > *must* be declared unsafe - you can't pass ByteArrays to safe ccalls). I think, here the context got lost: I want to expose a Haskell function with a string result rather than calling a C function from Haskell. > > 3) Who is responsible for freeing the memory of the string result? I > > suppose this should be done outside. But what to do that GHC's garbage > > collection doesn't free it automatically? > > The ByteArray is freed automatically by GHC's garbage collector. If you > need something more permanent, use malloc/free and the functions from > Storable to do the marshalling. For instance, how would you define a function like revstr :: String -> String revstr s = reverse s for foreign export? (The conversion of the string argument I handled like this:) strlength :: Addr -> IO Int strlength cstr = do s <- unpackCStringIO cstr return (length s) foreign export stdcall strlength :: Addr -> IO Int Cheers, Christian P.S. I think, some information on the handling of typical string conversion problems would be an interesting topic for GHC's user's manual, too.

1 0

RE: Select.hSelect & Threads
by Simon Marlow 13 Nov '00

13 Nov '00

> Will Select.hSelect block all running Haskell threads? I > assume it does. However, > the small explanation at the bottom of the documentation > seems too convoluted to > me to convey it's meaning. How about adding "Remember that > this will *block* *all* > *your* *threads*" to it? Thanks. I've rewritten this section to be clearer. It does indeed block all Haskell threads. Cheers, Simon

1 0