- Glasgow-haskell-users

ghc-4.xx Alpha port?
by Alex Ferguson 30 Nov '00

30 Nov '00

Hi guys. Has anyone been so rash as to try this? Any indications as to the likely "degree of difficulty"? I'd have a go myself, but I'm rather busy with teaching. (Which is ironic, since teaching is what I want it for...) Cheers, Alex.

1 0

Exception Handling
by Smelly Pooh 28 Nov '00

28 Nov '00

I'm writing an application at the moment (in Haskell duh) and the issue of exception handling has come up. I don't want to use Maybe (because that would destructure the code somewhat) or any kind of Monad and I've settled on the idea of SPJs Exception extension. The idea is to create a data type with a different constructor per exception as in data MyException = Ex1 | Ex2 | Ex3 then use throwDyn/catchDyn to throw and catch it. Unfortunately this requires MyException to be an instance of class Typeable, and the documentation on that is quite sparse. Any advice or pointers would be greatly appreciated

2 1

New InstallShield: no more DLLs
by Reuben Thomas 27 Nov '00

27 Nov '00

I've put up a new InstallShield for GHC 4.08.1 (Windows edition). This no longer contains DLLs and import libraries for the libraries, so you have to use the compiler with -static. I intend to stick to this scheme in future releases (probably replacing -static with -dynamic), as GHC derives few benefits from DLLized libraries, and a lot of disadvantages. Also, there is at present an unresolved and deep-seated bug (possibly not even in GHC) that prevents some very simple DLLized programs from working. Users of DLLs need not despair: one important (and, to the best of my knowledge, fully working) version of DLL building remains: you can still build static DLLs, that is, DLLs in which all the code has been compiled statically, so that all the necessary library code is linked into the DLL. Hence, you can still build DLLs to be called from other languages, or to be wrapped up as COM components, or whatever. Finally, one nice side effect is that the size of the distribution is nearly halved: it now weighs in at a little over 12Mb. -- http://sc3d.org/rrt/ | violence, n. bravery for cowards

1 0

unsubscribe glasgow-haskell-users
by Wooseok Yang 25 Nov '00

25 Nov '00

unsubscribe glasgow-haskell-users

1 0

types from ghc - got them!
by Bernard James POPE 21 Nov '00

21 Nov '00

Hi again, For my previous 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 I can now get the following output: ==================== Bernie: All Binder TypeSigs ==================== main :: IO () plus :: forall a. (Num a) => a -> a -> a fred :: forall a. (Num a) => a -> a -> a myid :: forall t_aMv. t_aMv -> t_aMv Which is exactly what I want. Turned out to be quite simple in the end. Thanks a lot for all your help Simon. Just out of curiosity, do you think that this sort of output would be useful for other people? I don't know what your plans are for GHCi, but you may be considering a mode that prints types out, something like :t in hugs. I always found it frustrating in hugs that I couldn't get the types of locally defined values. My students also find this frustrating, and it sometimes causes them to avoid local definitions. Obviously there are issues with type variables which are quantified outside the local definition, but careful naming of things should be able to fix this. Regards, Bernie. Simon Peyton-Jones writes: > 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

2 1

RE: types from ghc - got them!
by Simon Peyton-Jones 21 Nov '00

21 Nov '00

Well done. We're blazing away on GHCI (an interactive version of GHC) at the moment, including a user interface. When it's usable, perhaps you'd like to look at it with a view to adding this feature? Simon | -----Original Message----- | From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU] | Sent: 21 November 2000 06:43 | To: glasgow-haskell-users(a)haskell.org | Cc: bjpop(a)cs.mu.OZ.AU | Subject: types from ghc - got them! | | | Hi again, | | For my previous 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 | | I can now get the following output: | | ==================== Bernie: All Binder TypeSigs | ==================== | main :: IO () | plus :: forall a. (Num a) => a -> a -> a | fred :: forall a. (Num a) => a -> a -> a | myid :: forall t_aMv. t_aMv -> t_aMv | | Which is exactly what I want. Turned out to be quite simple | in the end. | | Thanks a lot for all your help Simon. | | Just out of curiosity, do you think that this sort of output would be | useful for other people? I don't know what your plans are for | GHCi, but you | may be considering a mode that prints types out, something like :t in | hugs. I always found it frustrating in hugs that I couldn't | get the types | of locally defined values. My students also find this | frustrating, and it | sometimes causes them to avoid local definitions. Obviously | there are issues | with type variables which are quantified outside the local | definition, but | careful naming of things should be able to fix this. | | Regards, | Bernie. | | | Simon Peyton-Jones writes: | | > 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 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

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