April 2002 - Glasgow-haskell-users

RE: ANNOUNCE: Object I/O released
by Krasimir Angelov 08 Apr '02

08 Apr '02

--- Peter Achten <peter88(a)cs.kun.nl> wrote: > Perhaps there is an interesting alternative that > covers all GOOD points and has fewer BAD points. Some pieces of library can be simplified if redefine: data WindowLSHandle ls ps = WindowLSHandle { wlsState :: ls , wlsHandle :: WindowHandle ls ps } as data WindowLSHandle ls ps = WindowLSHandle { wlsState :: MVar ls -- or IORef ls , wlsHandle :: WindowHandle ls ps } That let Object I/O to manage local state but simplifies implementation of WindowDevice (see WindowDevice.hs). There isn't need of fixIO and not need to use of build function. This also simplifies creation of modal dialogs and synchronous message passing. The current implementation uses unsafeTypeCast function which is not a good idea. In this implementation the type system is still complicated but my decision is just to skip type declarations and let compiler to resolve function types for me. In my experience with Object I/O I notice that type error is usually logical error. So types for me isn't a trouble. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

1 0

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

08 Apr '02

I don't know how to make existentials "know" about functional dependencies. In the type system that GHC implements, your example fails, and I don't see any meaningful way to make it succeed. But maybe someone else does. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 08 April 2002 10:30 | To: Simon Peyton-Jones; GHC List | Cc: Mark Shields | Subject: RE: Fundep/Existential Types in 5.03 | | | At 2002-04-08 02:15, Simon Peyton-Jones wrote: | | >Just leave out the existential in your defn of D! | >The (C a b) in the defn of f will do the job. | | I have another example, but this fails in 5.02.2: | | class C a b | a -> b | | data D a = forall b. (C a b) => MkD b | | f :: (C a b) => D a -> b | f (MkD b) = b | | Should this compile? It looks meaningful to me. | | | -- | Ashley Yakeley, Seattle WA | |

1 0

RE: ANNOUNCE: Object I/O released
by Simon Peyton-Jones 08 Apr '02

08 Apr '02

Krasimir | The version that I release is based entirely on LS | version. I think that it is more elegant and more | useful for customer. I'm delighted and impressed that you have completed the Object I/O port, but I don't think I agree with you about the MVar/LS issue. A note to other readers: the issue is whether it is better, from the programmer's point of view, to use MVars to manipulate state, or to use the state parameterisation that Clean uses. This issue is discussed in the paper by Peter Achten and mself http://research.microsoft.com/~simonpj/Papers/haskellobjectio.htm My defence of the MVar approach is not because I simply think that MVars are best for everything! It's because I have really struggled to understand the types in the Clean I/O system, and they become *so* much simpler when the state parameterisation is left out. And if I struggle, then I fear that novice programmers may be in real difficulty. I think that even Peter Achten thought this too, having done it both ways (but I should let him speak for himself). To respond to your points: | 1) In the MVAR version each event handler must like | this: | | eventHandler state = do | st <- takeMVar state | ... | ... | putMVAR state st' | | In LS version there isn't need of takeMVar/putMVAR and | the handler is more easy. | | 2) In MVAR version the event handlers in the device | definitions must be defined as curry functions | | Example MVAR: | state <- newMVAR (0::Int) | openWindow (Window NilLS [WindowClose (closeWin | state)]) | | Example LS: | openWindow (0::Int) (Window NilLS [WindowClose | closeWin]) Both are true, but you can easily wrap up the state passing if that is what you want: state <- newMVAR (0::Int) openWindow (Window NilLS [WindowClose (handle state closeWin)]) handle :: MVar a -> (a -> IO a) -> IO () handle m t = do { s <- getMVar m; r <- t s'; putMVar m s' } Now you can write closeWin :: WinState -> IO WinState if you want. Of course the reference to the state is still explicit, but I do not think that is a bad thing. It tells you where that MVar can be modified (and where it can't!). There might be two pieces of state for one component, one modified by one set of events and one by another, and it would be nice to make that apparent. | 3) Modification of local state doesn't mean | modification of device behaviour. The behaviour of the | device is described with both local state and internal | device data. This means that direct access to the | state isn't a good idea. In the LS version the local | state is encapsulated in the device and I think that | this is more OOP style. I don't understand this; you can encapsulate the MVars too, in just the same way: windowDevice = do { s <- newMVar 0; openWindow ... } No caller of WindowDevice can see the encapsulated MVar. Simon

1 0

RE: ghc-5.02.2-i386-unknown-linux.tar.bz2
by Simon Marlow 08 Apr '02

08 Apr '02

> 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? What do you get from 'ghc --version'? Simon

1 0

RE: ANNOUNCE: Object I/O released
by Krasimir Angelov 08 Apr '02

08 Apr '02

--- Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > Well done! > > You never responded to my question about MVars... > > Simon The version that I release is based entirely on LS version. I think that it is more elegant and more useful for customer. 1) In the MVAR version each event handler must like this: eventHandler state = do st <- takeMVar state ... ... putMVAR state st' In LS version there isn't need of takeMVar/putMVAR and the handler is more easy. 2) In MVAR version the event handlers in the device definitions must be defined as curry functions Example MVAR: state <- newMVAR (0::Int) openWindow (Window NilLS [WindowClose (closeWin state)]) Example LS: openWindow (0::Int) (Window NilLS [WindowClose closeWin]) 3) Modification of local state doesn't mean modification of device behaviour. The behaviour of the device is described with both local state and internal device data. This means that direct access to the state isn't a good idea. In the LS version the local state is encapsulated in the device and I think that this is more OOP style. Communication between devices is posible only with message dispatching, that is better object oriented tehnology. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

1 0

ANNOUNCE: Object I/O released
by Krasimir Angelov 08 Apr '02

08 Apr '02

The first release, 0.1, of Object I/O is now available. The Object I/O for Haskell library is a port of standard Clean Object I/O library. The general structure of the Haskell version is inherited from the original library but there are also few differences provoked from the languages differences. Object I/O allows Haskell programmers to build rich graphical user interface. This release support only Windows platform. Features include: * Modal and nonmodal dialogs * Nonmodal resizeable windows * Toolbars and menus * Various kind of controls and possibility to build custom controls * Layout manager for controls * Timers. The timer simplifies building of little games. See examples. * Support for file opening with "drag & drop" Quick reference is available from: <A href="http://free.top.bg/ka2_mail/objectio-ref.zip"> http://free.top.bg/ka2_mail/objectio-ref.zip</A> Binary package compiled with GHC-5.02.1 <A href="http://free.top.bg/ka2_mail/objectio.zip"> http://free.top.bg/ka2_mail/objectio.zip</A> Examples <A href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples">http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples</A> Source package <A href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io">http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io</A> __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

2 1

RE: Fundep/Existential Types in 5.03
by Ashley Yakeley 08 Apr '02

08 Apr '02

At 2002-04-08 02:15, Simon Peyton-Jones wrote: >Just leave out the existential in your defn of D! >The (C a b) in the defn of f will do the job. I have another example, but this fails in 5.02.2: class C a b | a -> b data D a = forall b. (C a b) => MkD b f :: (C a b) => D a -> b f (MkD b) = b Should this compile? It looks meaningful to me. -- Ashley Yakeley, Seattle WA

1 0

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