- Glasgow-haskell-users

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

ghc-6.4.1-july-12 test is all right
by Serge D. Mechveliani 21 Jul '05

21 Jul '05

I wrote today on testing of ghc-6.4.1-July-12-2005 > 3. Memory test with loading to ghci the whole DoCon test > (DoCon compiled with -O, tests compiled with -Onot) > and performing it: > 6.4.1-July-12 needs the minimum of 18 Mb, > 6.4, 6.4.1-June-14 need 10 Mb. > > -- ? This was some mistake of mine, probably. Now, I repeated the docon `make', and this test needs again 10 Mb, as in 6.4. Compiling the test part with -0 increases the needed memory to 14 Mb. I wonder, how could it appear the minimum of 18 Mb in previous session. So, all my tests for ghc-6.4.1-July-12 show almost the same (+- 3%) results as for ghc-6.4 and 5.02. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

testing 6.4.1-July-12
by Serge D. Mechveliani 21 Jul '05

21 Jul '05

This is on Simon Marlow's recent requests for the ghc-6.4.1-pre testing and benchmarking. I have installed ghc-6.4.1-July-12-2005 on Linux Debian by making it with ghc-6.4.1-June-14. 1. A simple test with list sorting and such, shows almost the same result as in ghc-6.4 and as in 5.02, for the performance, and minimal needed memory too. 2. The tests of ghc-6.4.1-July-12 on dumatel-1.03-pre (compex symbolic computations in prover) and docon-2.09-pre (complex computer algebra) look all right. I tested separately the performance, and minimal needed memory, for the tasks of 3-variable polynomial GCD and bi-variable factoring. It shows almost the same as in 6.4 and 5.02. 3. Memory test with loading to ghci the whole DoCon test (DoCon compiled with -O, tests compiled with -Onot) and performing it: 6.4.1-July-12 needs the minimum of 18 Mb, 6.4, 6.4.1-June-14 need 10 Mb. -- ? I am not very sure about 6.4 and 6.4.1-June-14, this may be a bug in old DoCon documenation. If the GHC developers need to repeat and make sure about this, let them ask me, and I would send them docon-2.09-pre, with description of what precisely to apply. Personally, I would not like now to re-install 6.4. On the other hand, this 1.8 factor difference looks suspicious, it worths to make sure. 4. A problem with the package clash in self-make. Now, Simon says, it will be fixed. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: GADTs and pedagogy was Re: GADTs and fundeps
by Simon Peyton-Jones 21 Jul '05

21 Jul '05

| > You mean, if the data type being defined doesn't actually use the | > generality of GADTs, allow GADT syntax, and deriving() too? | | Yes, that would be very nice for the HaskellDemo and new users. | I'd definitely switch all of my non-GADT datatypes to use that. I finally got around to doing this; turned out to be trivial. Record syntax aside, you can now declare any Haskell-98 data type using the GADT-style where-clause syntax, including 'deriving'. Simon

1 0

RE: GHC 6.4.1 for Solaris
by Simon Marlow 21 Jul '05

21 Jul '05

On 20 July 2005 16:31, herington, dean wrote: > I'm trying to deploy GHC 6.4.1 on a Solaris 5.9 machine. I installed > the binary release (in-place) from > <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris 2> > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2 > <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris 2.tar.bz2> > .tar.bz2, but it needs libreadline.so.5, libncurses.so.5, and > libgmp.so.3, which my machine lacks. How should I obtain these > shared libraries? On Solaris, the only way is to download, build and install each one. Cheers, Simon

1 0

Functional Dependencies
by Dirk Reckmann 21 Jul '05

21 Jul '05

Hello everybody! I wanted to have some fun with functional dependencies (see http://www.cs.chalmers.se/~hallgren/Papers/wm01.html) and tried some examples from this paper as well as some own experiments. The idea is to use the type checker for computations by "abuse" of type classes with functional dependencies. The example in the attached file is taken from the above paper. Due to the functional dependencies, I expected the type of seven to be uniquely determined to be (Succ (Succ (Succ ...))), i. e. seven, but ghc (version 6.4) gives me following error message: Add.hs:14:0: Couldn't match the rigid variable `a' against `Succ s' `a' is bound by the type signature for `seven' Expected type: Succ s Inferred type: a When using functional dependencies to combine Add (Succ n) m (Succ s), arising from the instance declaration at Add.hs:11:0 Add (Succ (Succ (Succ Zero))) (Succ (Succ (Succ (Succ Zero)))) a, arising from the type signature for `seven' at Add.hs:13:0-77 When generalising the type(s) for `seven' However, using the definition of Add to define Fibonacci numbers does work, and a similar function declaration can be used to compute numbers by the type checker. The same definition of Add works in Hugs... So, is this a bug in ghc, or am I doing something wrong? Thanks in advance, Dirk Reckmann

1 0