- Glasgow-haskell-users

Re: An answer and a question to GHC implementors [was Re: How to make Claessen's Refs Ord-able?]
by Ashley Yakeley 09 Apr '02

09 Apr '02

At 2002-04-08 11:33, John Meacham wrote: >this usage of unsafePerformIO is such a staple of real-world Haskell >programming, it seems there should be some language (or experemental >compiler *wink wink ghc nudge*) support for it. Sounds like a bad habit that shouldn't be encouraged to me. Still, if there is a way to support this safely, perhaps it should be allowed. I'd like to see a compiler flag that made all "unsafe" calls compiler errors. I'd put it into package javavm so that anyone using JVM-Bridge would have it turned on. -- Ashley Yakeley, Functional Purist Rank 2 Knight, Order of the Polymorphic Typed Lambda Calculus Seattle WA

1 0

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

08 Apr '02

At 11:40 AM 4/8/2002 +0100, you wrote: > > 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'? It came from the haskell.org download page. Version 5.02.1 was previously installed, as Serge Mechveliani inquired. I installed it as the super-user at the root of the file system. Perhaps I should now consider Version 5.02.3, but the problem may recur. I got this version of RHL from RH over the Web and finally realize that I need to register with RH for support. That is the ultimate solution, but there may be a delay in executing it. It is at least worth understanding. Thanks, Byron Hale byron.hale(a)einfo.com >Simon >_______________________________________________ >Glasgow-haskell-users mailing list >Glasgow-haskell-users(a)haskell.org >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: An answer and a question to GHC implementors [was Re: How to make Claessen's Refs Ord-able?]
by Simon Marlow 08 Apr '02

08 Apr '02

> A while back I asked how to make the Ref's from Koen Clasessen's PhD > thesis Ord-able for the purpose of making them keys for efficient > finite maps. > > Koen quickly responded with a clever implementation which attaches the > values to the keys. While I don't rule out eventually making use of > it, this solution has the drawback of requiring lookups in the finite > map to be inside the ST or IO monad. > > Josef Svenningsson asked if I had tried adding > {-# NOINLINE refWInt #-} > I had (quite hopefully.) It doesn't work. After fiddling a bit to > get a sense of what works and what doesn't, I tried: > {-# INLINE refWInt #-} > . This does the trick! I've included the working code (which differs > from that of my original message only by the addition of the INLINE > directive) below. > > My question to the GHC implementors is: what's going on here? Can you > give us (at least Josef and I are confused) any help in predicting how > unsafePerformIO will behave? I'm afraid the answer is just "unsafePerformIO is called *unsafe*PerformIO for a reason"! You're using it in an inherently unsafe way here - the result of the program depends on whether the compiler duplicates the expression or not, something which it is normally free to do without affecting the meaning of the program. However, it is possible to have global top-level references using unsafePerformIO if you're very careful about it. In GHC we do something like this: {-# NOINLINE global_var #-} global_var :: IORef Int global_var = unsafePerformIO (newIORef 42) the NOINLINE pragma is used to ensure that there is precisely *one* copy of the right hand side of global_var in the resulting program (NOTE: you also need to compile the program with -fno-cse to ensure that the compiler doesn't also common up the RHS of global_var with other similar top-level definitions). Cheers, Simon

2 1

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