- Glasgow-haskell-users

RE: Fundep/Existential Types in 5.03
by Simon Peyton-Jones 08 Apr '02

08 Apr '02

Ashley Just leave out the existential in your defn of D! The (C a b) in the defn of f will do the job. But your example nevertheless does expose a delicate interaction in the type checker. 5.02.2 happened not to expose the functional dependency, so it simply use the (C a b) that f provided. 5.03 does expose the dependency, and so makes the two b's the same, which is what gives the error message. It's a problem that some subtlety in the inference algorithm (I don't even know what it is) changes the behaviour. I don't know how to fix this, but perhaps someone else does. GHC makes all type abstractions and applications explicit, so the two b's really can't be the same: they don't have the same scope. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 06 April 2002 02:00 | To: GHC List | Subject: Fundep/Existential Types in 5.03 | | | Consider this: | | module Test3 where | | class C a b | a -> b where | m :: a -> b | | data D a = forall b. (C a b) => MkD a | | f :: (C a b) => D a -> b | f (MkD a) = m a | | This compiles fine under GHC 5.02.2. But under 5.03, it gives | an error: | | Model/Test3.hs:9: | Inferred type is less polymorphic than expected | Quantified type variable `b' escapes | When checking an existential match that binds | and whose type is D a -> b1 | In the definition of `f': f (MkD a) = m a | | I consider that the 5.02.2 behaviour is preferable, and that | this is a | perfectly good program. 'b' does not escape because it is | fundep on 'a', | which is specified in the type-signature. There can be only one. | | What was changed in 5.03 and why? | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

ghc-5.02.2-i386-unknown-linux.tar.bz2
by Byron Hale 08 Apr '02

08 Apr '02

Hi, I downloaded and installed ghc-5.02.2-i386-unknown-linux.tar.bz2 on my RedHat Linux 6.2 box (because RPM won't install the relevant RPMs). However, when I run "ghci," I get the message ... "GHC ... 5.02.1" ... What do you think is happening here? Best Regards, Byron Hale byron.hale(a)einfo.com

1 0

ghc 5.02.2 FFI question
by Bernard James POPE 08 Apr '02

08 Apr '02

Hi All, I've been playing with the FFI in GHC 5.02.2 I'm not sure if I'm using it correctly because I get a space leak in my program. Okay, very simply I want to construct a Haskell value from within a C function and pass it back to Haskell. In the following program I have an algebraic type called "Simple", which has one unary constructor "K". The idea is to pass a Stable pointer to K to the C code, and use rts_apply() to generate an application of the constructor and then use getStablePtr() to pass a stable pointer to the application back to Haskell. version of GHC is 5.02.2, operating system is Debian linux (woody), kernel 2.2.19, gcc version 2.95.4 Here's the Haskell code: -------------------------------------------------------------------------------- -- file: Main.hs module Main where import Foreign data Simple = K Double deriving (Show) -- first argument is a stable pointer to the constructor K -- result is a stable pointer to an application of K to a -- Double argument foreign import "leak" leak :: StablePtr (Double -> Simple) -> IO (StablePtr Simple) -- this is the important bit callLeak :: IO () callLeak = do kSPtr <- newStablePtr K simpleSPtr <- leak kSPtr simpleVal <- deRefStablePtr simpleSPtr freeStablePtr kSPtr freeStablePtr simpleSPtr print simpleVal main :: IO () main = repeatIO 100000 callLeak -- perform an IO action n times repeatIO :: Int -> IO () -> IO () repeatIO n io | n > 0 = do {io; repeatIO (n-1) io} | n == 0 = return () | otherwise = error $ "repeatIO: negative argument" -------------------------------------------------------------------------------- Here's the C code that implements the function leak(): -------------------------------------------------------------------------------- /* file: LeakC.c */ /* paths are hardwired at the moment */ #include "/home/bjpop/ghc-5.02.2/ghc/includes/Rts.h" #include "/home/bjpop/ghc-5.02.2/ghc/includes/RtsAPI.h" #include "LeakC.h" /* this just has the prototype for leak() */ StgStablePtr leak (StgStablePtr k_Ptr) { HaskellObj k; StgClosure *num; /* find the data constructor K, by dereferencing */ /* the stable pointer to it */ k = (HaskellObj) deRefStablePtr (k_Ptr); /* make some arbitrary Haskell Double value */ num = rts_mkDouble(230489.0923); /* I'm a bit worried about this last line of code */ /* --- is this reasonable to do? */ /* apply K to the Double and return a stable pointer */ /* to the result */ return (getStablePtr ((StgPtr)(rts_apply (k, num)))); } -------------------------------------------------------------------------------- Here's how I compile things: ghc -c LeakC.c ghc -package lang -fglasgow-exts -c Main.hs ghc -package lang -fglasgow-exts Main.o LeakC.o -------------------------------------------------------------------------------- And now some comments: Testing indicates that memory leaks proportionally to the number of times I call leak() (linear, I mean). My suspicion is that either I am doing something very stupid, and or data is not being collected completely after the stable pointers are freed. Note that I am careful to free every stable pointer that I allocate. I tried to dump the stable pointer table each time around to see whether there was anything obvious. My intial investigation did not show much, but I haven't looked too deeply. If I don't call the leak() function, but just construct a Simple value in the usual Haskell way the space leak disappears (even if I follow the newStablePtr/freeStablePtr route). The leak persists regardless of whether the result of calling the foreign function is in the IO monad or not. If it turns out that I am being stupid then I would appreciate some advice on how to achieve the desired outcome but no space leak. Alternatively, if my program is "reasonable" then I am happy to dive further into debugging it, but I didn't want to spend any more hours trying to find a bug if there actually isn't one to find. Thanks heaps, and sorry for the length of the post. Ooroo, Bernie.

1 0

How to make Claessen's Refs Ord-able?
by Mike Gunter 08 Apr '02

08 Apr '02

I'd like to extend the Ref type for observable sharing of Koen Claessen's Ph.D. thesis: > import IOExts ( IORef, newIORef, readIORef, writeIORef, unsafePerformIO ) > > newtype Ref a = MkRef (IORef a) > > ref :: a -> Ref a > ref x = MkRef (unsafePerformIO (newIORef x)) > > deref :: Ref a -> a > deref (MkRef r) = unsafePerformIO (readIORef r) > > (<==>) :: Ref a -> Ref a -> Bool > (MkRef ref1) <==> (MkRef ref2) = ref1 == ref2 to make it possible for the Refs to be the keys for efficient finite maps. I.e. I want something with at least an efficient Ord-like compare and maybe also a hash function. The closest I've got is: > type UniqTy = Integer > newtype RefWInt a = RefWInt (UniqTy, a) deriving (Show) > > curUniqInt :: IORef UniqTy > curUniqInt = unsafePerformIO (newIORef 0) > newRef a = do > v <- readIORef curUniqInt > writeIORef curUniqInt (v + 1) > return (v, a) > > refWInt x = RefWInt (unsafePerformIO (newRef x)) which works properly for this program alone: > tri_1 = (a, b, b1) > where a = refWInt "a" > b = refWInt "b" > b1 = refWInt "b" yielding (RefWInt (0,"a"),RefWInt (1,"b"),RefWInt (2,"b")). But if I add another copy of the same definition: > tri_2 = (a, b, b1) > where a = refWInt "a" > b = refWInt "b" > b1 = refWInt "b" and use it by uncommenting the second line here: > main = print tri_1 > -- >> print tri_2 I get: (RefWInt (0,"a"),RefWInt (1,"b"),RefWInt (1,"b")) (RefWInt (0,"a"),RefWInt (1,"b"),RefWInt (1,"b")) with ghc. (I get the desired (RefWInt (0,"a"),RefWInt (1,"b"),RefWInt (2,"b")) (RefWInt (3,"a"),RefWInt (4,"b"),RefWInt (5,"b")) with ghci.) Can I write code to always get the desired behavior? How? thanks, mike

3 3

GHC 4.08.2 binaries for OpenBSD i386 available
by dons＠cse.unsw.edu.au 06 Apr '02

06 Apr '02

Hi, I've finished a port of GHC 4.08.2 to OpenBSD i386. The binary package (12M) can be ftp'd from: ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/ghc-4.08.2.tgz This can be installed with the command (as root): pkg_add ghc-4.08.2.tgz You can remove the package with: pkg_delete ghc-4.08.2.tgz If you want to see how the package was built, or just like building from source, an OpenBSD ports system "port" (6k) is also available: ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/ghc-4.08.2-port.tgz Making sure you have a reasonably recent OpenBSD ports tree on the system, download the port to a convenient place (with >150M free) and: tar xvzf ghc-4.08.2-port.tgz cd ghc then, as root: make && make install This should pull the sources from the Haskell site, build the binary package and then install it. It takes around 4 hours on my P3 700 machine. You can uninstall this with pkg_delete, as above. Note that you will need both bzip2 and gmake to do the build. The port was built using the 2.9 branch of the ports tree so feedback from 3.0 or current ports tree users would be welcome. Send any bugs or suggestions to me at <dons(a)cse.unsw.edu.au>. I will work on getting 5.02.2 and 5.03 built and out soon. Thanks, Don

1 0

Fundep/Existential Types in 5.03
by Ashley Yakeley 06 Apr '02

06 Apr '02

Consider this: module Test3 where class C a b | a -> b where m :: a -> b data D a = forall b. (C a b) => MkD a f :: (C a b) => D a -> b f (MkD a) = m a This compiles fine under GHC 5.02.2. But under 5.03, it gives an error: Model/Test3.hs:9: Inferred type is less polymorphic than expected Quantified type variable `b' escapes When checking an existential match that binds and whose type is D a -> b1 In the definition of `f': f (MkD a) = m a I consider that the 5.02.2 behaviour is preferable, and that this is a perfectly good program. 'b' does not escape because it is fundep on 'a', which is specified in the type-signature. There can be only one. What was changed in 5.03 and why? -- Ashley Yakeley, Seattle WA

1 0

Dynamic loading with GHCi Linker
by Keean 05 Apr '02

05 Apr '02

[Firstly, appologies if this is a duplicate, my first mail did not appear on the list.] Summary so far: I want to dynamic load haskell code into a host haskell application (plug-in style) I have, as suggested, put together an interface for Linker.h, and written some little wrapper functions. I have a few questions though... (is there any documentation?) What are the integer return values from loadObj/resolveObjs/unloadObj ? What is the void* pointer returned from lookupSymbol - and how do I apply it if its a function. (my first guess was to import rts_apply) Finally, when I load the module there are unresolved symbols - will it link against the main program? Is there any way to get it to do this? (I would like to avoid dynamic loading dependancies if the code is already used by the main program) Keean

1 0

RE: explicitly quantified classes in functions
by Simon Peyton-Jones 05 Apr '02

05 Apr '02

| Ah yes, silly me. What I had in mind, I suppose, was | something more along the lines of: | | foo :: Double -> (exists q . Foo q => q) Correct. Currently you can only express this by wrapping the existential in a constructor: data R = forall q. Foo q => MkR q foo :: Double -> R Mark Shields and I wrote a paper about doing more fully fledged existentials, but it's quite a significant chunk of work to implement. http://research.microsoft.com/~simonpj/Papers/first-class-modules Simon

1 0

Re: explicitly quantified classes in functions
by John Hughes 04 Apr '02

04 Apr '02

Why can I not define the following (in ghc): > class Foo p where > instance Foo Double where > foo :: Double -> (forall q . Foo q => q) > foo p = p From my humble (lack of) knowledge, there seems to be nothing wrong here, but ghc (5.03) complains about unifying q with Double. Well, of course! The result has to have type (forall q . Foo q => q), but p actually has type Double. Of course GHC complains. The question is, why YOU think it is OK. And the answer is that you reason: there is only one instance of Foo, so when I say Foo q, that means q must be Double. But you're making the "closed world assumption", that you know all of the instances of Foo. The compiler doesn't, and for good reason. Suppose you were to export these definitions from the module where they appear, into another module which defines instance Foo Integer Now, of course, it should be OK to use Foo with the type Double -> Integer (since Foo Integer holds in this context). Yet clearly, the *definition* you gave cannot be used with this type. Hence the type is wrong. Of course, you could argue that if the definition of foo is *not* exported, then the compiler should use the closed world assumption and the program should be accepted. But it would be really weird if whether a definition is well-typed or not depended on whether or not it was exported... John

2 1

explicitly quantified classes in functions
by Hal Daume III 04 Apr '02

04 Apr '02

Why can I not define the following (in ghc): > class Foo p where > instance Foo Double where > foo :: Double -> (forall q . Foo q => q) > foo p = p >From my humble (lack of) knowledge, there seems to be nothing wrong here, but ghc (5.03) complains about unifying q with Double. I *can* write: > class Foo p where > instance Foo Double where > data T = forall q . Foo q => T q > foo :: Double -> T > foo p = T p which is very similar, except that the explicit universal quantification is happening in in the datatype and not the function type. why is the former disallowed? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 2