May 2002 - Glasgow-haskell-users

Re: composeList
by David Feuer 13 May '02

13 May '02

See comments below. On Sun, May 12, 2002, David Feuer wrote: > On Sun, May 12, 2002, Emre Tezel wrote: > > Hi all, > > > > I recently bought Simon Thompson's Haskell book. I have been doing the > > exercises while I read on. There are couple questions that I can not > > solve. Any help would be greatly appreciated. > > > > I got stuck on this question in Chapter 10. > > > > Define a function composeList which composes a list of functions into a > > single function. What is the type of composeList? > > > > I naively tried the following but the hugs compiler complained about the > > inferred type not being generic enough. > > > > composeList :: [(a -> b)] -> (c -> b) > > composeList [] = id > > composeList (x:xs) = x . (composeList xs) <snip> > You can do a lot better in Glasgow Haskell: > > data Fun a b = forall c . Comp (c -> b) (Fun a c) | End (a -> b) > > compose :: Fun a b -> a -> b --GHC needs this type signature > --to compile the program, but > --I don't understand why. > --Any tips? > compose (End f) = f > compose (Comp f l) = f . compose l Well, I figured out why the type signature is necessary (polymorphic recursion), but I don't understand the error message I got from GHC: cc.hs:5: Inferred type is less polymorphic than expected Quantified type variable `c' escapes When checking a pattern that binds f :: c -> b l :: Fun a c In the definition of `compose': compose (Comp f l) = f . (compose l) What makes it think that `c' escapes? This message had me staring at the code the wrong way for quite a while before I decided to add a type signature and see if that gave me any more useful information. > > f::Int -> Float > f x = fromIntegral x > > g::String -> Int > g = read > > h::Int -> String > h x = take x "123456789" > > main = do > putStrLn "hello!" > print $ compose (End (\x -> "Foo!")) 3 > print $ compose (Comp f (Comp g (End h))) 4 -- Night. An owl flies o'er rooftops. The moon sheds its soft light upon the trees. David Feuer

1 0

Prelude.catch vs. Exception.catch
by Ashley Yakeley 13 May '02

13 May '02

I notice that Prelude.catch and Exception.catch behave differently, even though they both have the same type signature (and name). Exception.catch catches exceptions that Prelude.catch does not. For instance, it is possible to bind pure functional exceptions into the IO monad using Exception.evaluate: peUndef :: String; peUndef = undefined; ioUndef :: IO String; ioUndef = Exception.evaluate peUndef; These can be caught with Exception.catch: main :: IO (); main = do { result <- Exception.catch (ioUndef) (\e -> return ("got exception: " ++ (show e))); hPutStr stderr (result ++ "\n"); }; got exception: Prelude.undefined ...but not with Prelude.catch: main :: IO (); main = do { result <- Prelude.catch (ioUndef) (\e -> return ("got exception: " ++ (show e))); hPutStr stderr (result ++ "\n"); }; Fail: Prelude.undefined What's up with that? -- Ashley Yakeley, Seattle WA

1 0

RE: ghci unload - profiling
by Simon Marlow 10 May '02

10 May '02

> Just a quick addition to my previous question- using the ghci > linker to > load object code, > I am currently using the following files from the system libraries: > > HSstd.o > HSstd_cbits.o > HSlang.o > HSlang_cbits.o > HSdata.o > HStext.o > HSnet.o > HSconcurrent.o > HSutil.o > HSutil_cbits.o > HSposix.o > HSposix_cbits.o > > However, when tring to profile the code I need to load profiling > versions of these objects, but > the ghci-linkers loadObject doesn't appear to be able to load the > libHSstd_p.a (nor the libHSstd.a) > library... how do I get the ghci-linker to link my profiling objects > against the profiling versions of the > system libraries. You can't do profiling inside GHCi. Compile the program into a standalone binary to do profiling. Cheers, Simon

3 2

RE: bug in ghc with {| |}
by Simon Peyton-Jones 10 May '02

10 May '02

Good point. That was going to be the syntax for type application, but it's not straightforward (e.g. what are the order of the type params?) so I never finished it. I'll remove it from the parser for now. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 07 May 2002 20:19 | To: GHC Users Mailing List | Subject: bug in ghc with {| |} | | | in ghci: | | NLP.Clustering> let x = 5x {| Int |} | *** Exception: typecheck/TcExpr.lhs:168: Non-exhaustive | patterns in function tcMonoExpr | | | i have no idea what {| and |} do, but i was messing around | with them and typed this in by accident and it raised an | exception. fyi. | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

RE: updating labelled fields
by Simon Peyton-Jones 10 May '02

10 May '02

| So, as it stands the proposal is to add the following pieces of sugar: | | 1) ({assignments}) becomes \x->x{assignments} | 2) x{as, field =, bs} becomes \y->x{as, field = y, bs} | 3) x{as, field, bs} becomes \f->x{as, field = f (field x), bs} ... | Assuming I can ever get my cvs'd copy of ghc to compile | (sigh), I would be willing to implement this if there are no | objections... Hal, it's fine for you to modify and distribute your copy of GHC, of course, but I'm not yet convinced that Simon and I want to put this change in the mainstream GHC. It's easier to add a feature than to remove it, and GHC already arguably suffers from feature-itis. (Perhaps, though, people will love your change and nag us to put it in. The more people that ask the keener we are to do something.) While you are thinking about implementation, don't forget the type checking part. I recall that correct type checking of Haskell records was a bit harder than it looked. Incidentally, I'm working with Tim Shead on a sort of meta-programming facility (somewhat like a fully-integrated Drift, only typechecked) that would let you generate update functions for each field automatically; that might help towards the same goal. Simon

1 0

RE: module namespaces with "Prelude"
by Simon Marlow 09 May '02

09 May '02

> All in all, dropping all implicit directories from the search > path gets my vote. "me too". I wasn't aware that Hugs did this, and GHCi certainly doesn't. It's reasonable to leave "." in the default search path, but adding an implicit root for an imported module will certainly lead to trouble - after all, we use hierarchical module names because the modules at the leaves of the tree are expected to overlap. Cheers, Simon

3 2

RE: ghci unload
by Simon Marlow 09 May '02

09 May '02

> Hmm, I have noticed a similar problem already... If I fork a thread on > some > loaded code which accesses some MVars, then unload the code > it SegFaults > - > however if I wait for the thread to terminate using another > MVar before > unloading > it works fine... On this basis it seems that you still can't guarantee > that the GC > won't fall over . This sounds like it might just be a bug. Can you boil it down to a small example which repeatably triggers the seg fault? > Is there no way of garbage collecting the object code (maybe using > some kind of finaliser) so that we free it when finished with > - avoiding > the problems > with forked threads as well? Finalizers (in the ForeignPtr sense) don't work well for object code because the pointers from the heap aren't just to closures: they are to info tables too, which aren't tracked by the garbage collector. It would theoretically be possible to build some special support into the garbage collector to reclaim object code when it is finally released, but it would be a lot of work for little benefit: GHCi is really just a development environment, it really isn't intended to be a platform for long-running programs. > As for the space leak... I have now noticed two different > space leaks - > one occurs whether or > not anything is reloaded - and is about 4K every time a > function from a loaded module is called. Are you sure this isn't just GHC's memory allocator claiming a new page? How did you measure this? > The other - on restart is about 100K - the modules being reloaded are > about 60K on disk - > so there appears to be another 30-40K loss. There will be some space allocated for the symbol table for the module, and various other structures. An extra 50% doesn't sound too unreasonable. Cheers, Simon

1 0

Re: ghci unload - profiling
by MR K P SCHUPKE 09 May '02

09 May '02

Just a quick addition to my previous question- using the ghci linker to load object code, I am currently using the following files from the system libraries: HSstd.o HSstd_cbits.o HSlang.o HSlang_cbits.o HSdata.o HStext.o HSnet.o HSconcurrent.o HSutil.o HSutil_cbits.o HSposix.o HSposix_cbits.o However, when tring to profile the code I need to load profiling versions of these objects, but the ghci-linkers loadObject doesn't appear to be able to load the libHSstd_p.a (nor the libHSstd.a) library... how do I get the ghci-linker to link my profiling objects against the profiling versions of the system libraries. Keean.

1 0

RE: ghci unload
by Simon Marlow 09 May '02

09 May '02

> I was wondering if anyone had any suggestions/advice on the > following... I am doing dynamic loading using bits of GHCi and it > all works very nicely. > > occasionally however I want to unload a module and reload > it... this > works fine however I remember from some other post that > the memory from the unload is not reclaimed. This would > explain the slow > memory creap I am seeing. > > So, finally, here's my question: why is it difficault to recover > this memory - is there any way of doing it - remembering that I am > not actually using anything from GHCi apart from the linker The problem, in a nutshell, is that it is difficult to guarantee that there are no references from the heap to objects or info tables in the code object we want to unload. This amounts to providing a hard guarantee that there are no space leaks in your program - we can try hard to make sure we don't have a space leak, but actually *promising* this isn't practical. We considered having the garbage collector flag an error if it found a reference to unloaded code, but decided against it because it would be impossible in general to prevent these kind of bugs. Do you have some measurements on how much memory is being lost over time? I also know of several other ways that GHCi leaks memory during use, so it might not just be the object files. Cheers, Simon

2 1

ghci unload
by Keean Schupke 08 May '02

08 May '02

Hi, I was wondering if anyone had any suggestions/advice on the following... I am doing dynamic loading using bits of GHCi and it all works very nicely. occasionally however I want to unload a module and reload it... this works fine however I remember from some other post that the memory from the unload is not reclaimed. This would explain the slow memory creap I am seeing. So, finally, here's my question: why is it difficault to recover this memory - is there any way of doing it - remembering that I am not actually using anything from GHCi apart from the linker - a typical session might look like. initLinker load [lots of objects...] resolveObjects : load module1 load module2 resolveObjects : unload module1 load module1.1 resolveObjects : etc... Regards, Keean Schupke.

1 0