- Glasgow-haskell-users

RE: Contexts differ in length
by Simon Peyton-Jones 26 Jul '05

26 Jul '05

I revisited the typechecking of binding groups, partly to fix the shortcomings of SPECIALISE pragmas. On the way, I implemented the refined dependency analysis described by Mark Jones in "Typing Haskell in Haskell". As a result, this "Contexts differ in length" problem has gone away. Robert, would you like to give it a try? Your example below is now part of GHC's test suite. It'll be in the next major release, but not in 6.4. Simon | -----Original Message----- | From: Robert van Herk [mailto:rherk@cs.uu.nl] | Sent: 24 May 2005 13:31 | To: glasgow-haskell-users(a)haskell.org; Simon Peyton-Jones | Subject: Contexts differ in length | | Hi all, | | A while ago I sent an email to the glasgow haskell users maillinglist to | explain how the "Contexts differ in length" feature (or bug :-)) | restricted me in writing a haskell application. I was hoping for a | reply, however I didn't receive one (yet). | | Therefore, I will explain the problem again: | | I am writing (for my master's thesis project) a webdevelopment framework | in Haskell, with features somewhat comparable to Apple's WebObjects. | Amongst others, session state and database interaction is transparent, etc. | | In my framework, functions that generate HTML are called WFComponents. | These functions are monadic since they can generate IO (because they may | do database interaction etc). Also, components can generate links to | other components. However, since component a may generate a link to | component b (so that when the user clicks that link component b will be | evaluated) and component b may link to component a, there will occur | errors when I try to do this, since the contexts of component a and b | may not be the same. A minimal example of this will be something like: | | {-# OPTIONS -fglasgow-exts #-} | | module Main where | import Data.IORef | | class MyReader r v | r -> v where | myRead :: r -> IO v | | data R v = R (IORef v) | instance MyReader (R v) v where | myRead (R v) = | do v <- readIORef v | return v | | | a :: IO () | a = | do r <- createReader | b r | | b :: MyReader r Int => r -> IO () | b r = | do i <- myRead r | if i > 10 | then a | else putStrLn (show i) | | createReader :: IO (R Int) | createReader = | do ref <- newIORef 0 | return (R ref) | | | | A real example will be a bit more complicated, but this is basically | what I need to do and currently am not able to. Of course, when needed, | I can show you the real example. Somewhere in the history of this | mailling list I read that people have had this program before, but only | in toy programs. However, I am experincing this problem currently in | something that is not a toy program. Therefore, my question is if it | would be possible to lift this constraint on the language, and also, if | the developers of GHC are currently planning to do this... | | Thanks, | | Robert

2 1

ghc-pkg query feature request
by Lennart Kolmodin 26 Jul '05

26 Jul '05

Hi! When working with multiple versions of a package you often want to use the most recent version. A feature that would help for package systems is to be able to query ghc-pkg for the best version, or to list the versions in increasing version order. Something like: $ ghc-pkg best_version Cabal Cabal-1.1.1 $ ghc-pkg versions Cabal Cabal-1.0 Cabal-1.1.1 You get the picture. Obviously, this feature isn't critical since we could use 'ghc-pkg list' and work our way from there, but it would be nice. If you like the idea we might send you a patch. What do you think? Cheers, Lennart Kolmodin -- "The only thing that interferes with my learning is my education." -- Albert Einstein

1 0

RE: the FFI and C reference counting
by Simon Marlow 25 Jul '05

25 Jul '05

On 24 July 2005 14:05, Peter Gammie wrote: > After much head scratching I can only think that the following is > happening: > > 1. Create BDD, BDD.refcount++, add finalizer. > 2. BDD becomes unreferenced but not yet GC'd. > 3. Call BDD operation returning the same BDD as step 1. (call it BDD') > 4. GHC's GC kicks in and BDD.refcount--. (*) > 5. BDD'.refcount++, add finalizer. > > At (*), CUDD deallocates BDD (== BDD') and BDD' becomes a dangling > pointer. > > Is this plausible? Looks plausible to me. The API is being a bit naughty by not incrementing the reference count on an object it returns - this would be ok if the API function returning the object can be sure that the ref count is already at least 1, but in this case it appears that you have been handed an object which has a ref count of possibly 0, which seems bad. I wonder what reasoning the API is using to justify this. COM is another reference-counted API. In COM, the convention is that a returned object will have its reference count already bumped, you have to explicitly Release() it. See QueryInterface(), for example. However, passing an object to a method in COM doesn't require bumping the reference count, but the caller is holding the object so it can be sure the reference count remains non-zero for the duration of the call. > On a related note: what impact will multi-core GHC have on code like > this? > I get queasy thinking of how it will interact with all those > non-threadsafe C libraries bound in a style similar to the above... Using COM in the Visual Studio extension, we ran into trouble just using the multi-threaded RTS, never mind multi-core. The problem is that the finalizer runs in a different thread than the original thread that created the object, so if the act of decrementing the reference count is not a thread-safe operation, you're in trouble. We had to switch to explicit reference counting operations instead of finalizers in COM code (it isn't too bad, actually). Cheers, Simon

1 0

RE: Performance week 25/6-29/6
by Simon Marlow 25 Jul '05

25 Jul '05

On 25 July 2005 10:07, Ketil Malde wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> We're interested in performance issues with both GHC itself and >> GHC-compiled code. > > I can think of a couple of things. > > One is the performance of Int64 (which unsurprisingly is inferior to > Int(32) but more surprisingly, also to Integer). I've reported it > previously, but can dig it up again, if desired. Added to the list, thanks. > The other is probably not as relevant, but I'll mention it anyway. I > occasionally use rather large arrays, and UArrays can save a > considerable amount of space. Sometimes, however, I want to store > more complex structures than those UArrays are provided for. It seems > to me that what I really want are *strict* arrays (which the compiler > then can unbox automatically), and that these could be provided for > any (single constructor) data type? Manuel Chakravarty's flattened arrays are what you want; I'm not sure of the implementation status though. Also, once we have associated types it will be easier to do this (see the associated types paper for an example). Cheers, Simon

1 0

Performance week 25/6-29/6
by Simon Marlow 25 Jul '05

25 Jul '05

Hi folks, We're planning to attack performance issues next week. I've put up a wiki page here: http://www.haskell.org/hawiki/GhcPerformance We're interested in performance issues with both GHC itself and GHC-compiled code. Please add any programs or modules that you think should compile/run faster, or any hair-brained schemes you have for improving performance. And free free to get involved! If you have anecdotes, information about any of the known issues, or want to tackle something, post here or cvs-ghc(a)haskell.org, or join the #haskell IRC channel on irc.freenode.net. Cheers, Simon

2 1

RE: Lambda Lifting and Haskell
by Simon Peyton-Jones 25 Jul '05

25 Jul '05

You're not asking a question about Haskell, but about Haskell implementations, and they may make different choices. GHC, for example, does not do lambda lifting. See http://research.microsoft.com/copyright/accept.asp?path=/users/simonpj/p apers/spineless-tagless-gmachine.ps.gz&pub=34 for a summary of what it does do. Other implementations might do lambda lifting. I'm not sure. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Marco Morazan | Sent: 23 July 2005 22:52 | To: glasgow-haskell-users(a)haskell.org | Subject: Lambda Lifting and Haskell | | Dear All, | | Apologies in advance if you are getting this a second time. I am | unsure if my last posting was successful. | | I am interesting in learning how and when are Haskell programs lambda | lifted. Are all functions always made global? Any pointers are | appreciated. | | Best wishes, | | Marco | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

the FFI and C reference counting
by Peter Gammie 24 Jul '05

24 Jul '05

Hello, I have a question about the FFI and reference counted objects in C land. This is a bit complicated, unfortunately. The problem arises in trying to integrate a BDD package with GHC's storage manager. One of the properties of BDD packages is that the name of a BDD (a pointer or an int) is canonical (wrt boolean functions), no matter how it is constructed; so for example: True True and True are both given the same identifier. The user of the C library must increment and decrement reference counts attached to these identifiers. (If you are unfamiliar with BDDs, just think of a bunch of objects stored in a hashtable where several keys map to each object, each of which is created on first access via any key and garbage collected when it's reference count becomes zero. The key property is that the same object can be returned using different keys.) I've had success with the CMU/Long package using code of the form (some of it generated by c2hs): newtype BDDManager = BDDManager (Ptr (BDDManager)) newtype BDD = BDD (ForeignPtr BDD) withBDD (BDD fptr) = withForeignPtr fptr bdd_manager :: BDDManager bdd_manager = unsafePerformIO bdd_init addBDDfinalizer :: Ptr BDD -> IO BDD addBDDfinalizer bddp = liftM BDD $ newConcForeignPtr bddp bddf where bddf = bdd_free bdd_manager bddp {-# INLINE addBDDfinalizer #-} -- sample BDD operation. bddNOT = unsafePerformIO $ withBDD x (bdd_not bdd_manager) >>= addBDDfinalizer where all free variables should be FFI functions if I got this excerpt right. (This BDD package does the refcount increment for us before returning the BDD, which avoids the following problem.) This approach fails to work for the CUDD library, which sometimes claims I have called the dereference function too many times. It requires an explicit refcount increment on each BDD returned, so "addBDDfinalizer" becomes: addBDDfinalizer :: Ptr BDD -> IO BDD addBDDfinalizer bddp = do cudd_Ref bddp liftM BDD $ newConcForeignPtr bddp bddf where bddf = do cudd_RecursiveDeref ddmanager bddp return () {-# INLINE addBDDfinalizer #-} After much head scratching I can only think that the following is happening: 1. Create BDD, BDD.refcount++, add finalizer. 2. BDD becomes unreferenced but not yet GC'd. 3. Call BDD operation returning the same BDD as step 1. (call it BDD') 4. GHC's GC kicks in and BDD.refcount--. (*) 5. BDD'.refcount++, add finalizer. At (*), CUDD deallocates BDD (== BDD') and BDD' becomes a dangling pointer. Is this plausible? I am wondering if anyone else has had a similar problem (e.g. with GTK's reference counting) and has a nicer solution than writing wrappers that increment the reference count before returning to GHC's runtime. If I am on the right track then it seems that requiring the user to increment the reference count on each returned object is a pretty bad design decision. If I'm not, some debugging hints would be most welcome. On a related note: what impact will multi-core GHC have on code like this? I get queasy thinking of how it will interact with all those non-threadsafe C libraries bound in a style similar to the above... thanks, peter

1 0

Lambda Lifting and Haskell
by Marco Morazan 23 Jul '05

23 Jul '05

Dear All, Apologies in advance if you are getting this a second time. I am unsure if my last posting was successful. I am interesting in learning how and when are Haskell programs lambda lifted. Are all functions always made global? Any pointers are appreciated. Best wishes, Marco

1 0

Lambda Lifting and Haskell
by Marco Morazan 21 Jul '05

21 Jul '05

Hello everyone, Do what degree are the different dialects of Haskell being lambda lifted? Are there any performance studies? Any pointers to the literature will be welcomed. Best wishes, Marco

1 0

Performance week 25/6-29/6
by Bauer, Christoph 21 Jul '05

21 Jul '05

Hi, I must start by saying, that I don't have any knowledge about ghc internals. Performance of haskell programs seems to me heavily depended on the data structures of a simple linked lists. Because of the amount of cons-cells, simple linked lists aren't very GC-friendly. There is a paper about a replacement, called VLists. http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200244.pdf So maybe VLists could be used in haskell internally for lists and strings. Best regards, Christoph Bauer Dipl. Inf. LMS Deutschland GmbH Luxemburgerstr. 7 D-67657 Kaiserslautern T +49 631 303 22 152 mailto:Christoph.Bauer@lms-gmbh.de http://www.lmsintl.com

1 0