- Haskell-Cafe - Haskell.org

REMINDER: Contributions to the HC&A Report (November 2004 edition)
by Andres Loeh 27 Oct '04

27 Oct '04

Dear Haskellers, the deadline for the November 2004 edition of the Haskell Communities and Activities is approaching quickly -- but there are still a few days left to make sure that the report contains a section on *your* project, on the interesting stuff that you've been doing, using or affecting Haskell in some way. In particular, any information regarding upcoming, Haskell-related, events is highly appreciated (conferences, workshops, summer schools ...). Many FP research groups have not yet updated their reports. Furthermore, please have a look at http://haskell.org/topics.html * Is your project listed, but not yet updated? Please write a short update! * Is a project listed that you are no longer working on? Write up what you are working on instead, and tell me if someone else has picked up the project. * Is something you have heard about not in the list? Please let me know ... There is still time to write a completely new entry, on a new compiler, tool, library, company, user group, idea, ... -- as long as there is a connection to the Haskell language, there is a place for it in the report! Submissions are due by the end of this week, that is Friday, 29 October 2004. Please mail your entries to hcar at haskell dot org, in plain text or pseudo-(La)TeX format. I look forward to receiving your contributions. Thanks a lot, Andres (current editor) -- Haskell Communities and Activities Report (http://haskell.org/communities) 11/2004 edition submission deadline: 29 October 2004 <hcar(a)haskell.org>

2 2

RE: [Haskell-cafe] Are handles garbage-collected?
by Simon Marlow 26 Oct '04

26 Oct '04

On 24 October 2004 20:51, Sven Panne wrote: > IMHO it would be best to use explicit bracketing where possible, and > hope for the RTS/GC to try its best when one runs out of a given > resource. Admittedly the current Haskell implementations could be > improved a little bit in the last respect. Indeed, GHC could/should try to free up file descriptors when they run out. It's a bit tricky though. At the moment performGC doesn't actually run any finalizers. It schedules a thread to run the finalizers, and you hope the thread runs soon. So if you're running performGC for the purposes of finalization, then almost certainly (performGC >> yield) is better. I've been wondering whether having a more synchronous kind of finalizer would be a good thing. Nevertheless, I agree with the general sentiment on this thread that file descriptors shouldn't be treated as a resource in the same way as memory. Cheers, Simon

15 22

RE: [Haskell-cafe] Re: Are handles garbage-collected?
by Simon Marlow 26 Oct '04

26 Oct '04

On 26 October 2004 10:42, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I didn't mean fully synchronous, just "more synchronous". For >> example, the finalization routine could be run directly after >> garbage collection. Hugs & nhc98 already do this, because they don't >> support Haskell finalizers. > > Actually, nhc98 supports both C and Haskell finalisers, with the same > signatures as in ghc: > > newForeignPtr :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a) > newConcForeignPtr :: IO () -> Ptr a -> IO (ForeignPtr a) > > C finalisers are run during garbage collection, Haskell finalisers > are run immediately afterwards. In fact, you cannot run a Haskell > finaliser during GC, because you don't have a valid heap to run it in. But don't you run into problems in the implementation of newConcForeignPtr, when the Haskell finalizer needs the value of a thunk that was already under evaluation when the GC happened? ie. the need for concurrency that stopped this from becoming part of the official FFI. Cheers, Simon

2 1

Re: Are handles garbage-collected?
by oleg＠pobox.com 26 Oct '04

26 Oct '04

Simon Marlow wrote: > I've been wondering whether having a more synchronous kind of > finalizer would be a good thing. Hans Boehm in his POPL2003 paper "Destructors, Finalizers, and Synchronization" persuasively argued that finalizers _must_ be asynchronous. That assertion is the title of Section 3.5 of the paper. Peter Simons wrote: > input -> iodriver --> connection handler --+ > | /|\ | > output <--+ +-----------------------------+ > (Event, State) > ... > The I/O driver is a StateT monad which calls the (various) > connection handlers every time new input is available from > the network. The handlers are StateT monads, too, and their > respective state is stored in the I/O driver's state when > they return. > ... > The only solution I would know is to put the entire state of > the connection handler into an MVar, so that any changes to > it are immediate for the I/O driver. But that approach feels > like overkill to me. It seems you don't need to store the whole state in MVar: it's enough to store a `clean-up' action. Suppose there exists an MVar known to both a connection handler and the iodriver. The type of MVar's value is Maybe (IO ()). When the connection handler opens a Handle, it places a Just action that will close the handle. If the connection handler makes it to the end without getting an exception, it, right before returning to the iodriver, replaces that cleanup action with Nothing. The iodriver, upon getting control back, checks the MVar and executes whatever action is outstanding. The action can refer to any context it needs for the clean-up. Come to think of it, perhaps MVar is overkill. From your description, it seems that each connection handle has its own private piece of state inside the iodriver state. Perhaps it is not so much to ask to add an IORef (Maybe (IO ())) to that state. The iodriver will check that IORef upon getting control back from the control handler; Or the driver can scan all these IORefs upon receiving an event, an exception, etc. Perhaps a more general approach is a special Handle leasing component. Can we assume that a connection handler has a specific ID? Can we assume that all alive connection handlers can be enumerated (it seems so from the above description: iodriver is aware of all alive connection handlers). If these assumptions hold, we can introduce one level of indirection. Whenever a connection handler needs a Handle, it applies to the Lord of Handles (LoH), passing its own id and the file name. The LoH gives an id of a handle (or the handle itself). The LoH also stores the allocated Handle and the component ID in its tables. From time to time (or on certain events) the LoH checks all the open handles to see if the corresponding connection handlers are still alive.

2 1

RE: [Haskell-cafe] Re: Are handles garbage-collected?
by Simon Marlow 26 Oct '04

26 Oct '04

On 26 October 2004 03:51, oleg(a)pobox.com wrote: > Simon Marlow wrote: >> I've been wondering whether having a more synchronous kind of >> finalizer would be a good thing. > > Hans Boehm in his POPL2003 paper "Destructors, Finalizers, and > Synchronization" persuasively argued that finalizers _must_ be > asynchronous. That assertion is the title of Section 3.5 of the paper. I didn't mean fully synchronous, just "more synchronous". For example, the finalization routine could be run directly after garbage collection. Hugs & nhc98 already do this, because they don't support Haskell finalizers. Just a thought, anyway (and I've read that paper, it's great). Cheers, Simon

2 1

Re: [Haskell-cafe] Relational Algebra post
by Graham Klyne 25 Oct '04

25 Oct '04

Cool! That goes on my list for further study. (I have a work-in-progress of something similar for description logics.) #g -- At 15:01 22/10/04 -0700, Brian Beckman wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C4B882.A1CF3A2A" > >on my blog >(<http://weblogs.asp.net/brianbec>http://weblogs.asp.net/brianbec) , i've >posted a couple of Haskell gadgets. One is a simulator for the "relational >algebra" of database theory. The other is just an expansion of one of Paul >Hudak's derivations of State monads. > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

fst and snd as record selectors
by Lemming 24 Oct '04

24 Oct '04

The pair data type is quite a regular data type, where (x,y) is syntactic sugar for (,) x y, right? So, why aren't 'fst' and 'snd' record selectors of the pair data type? The definition of pair could be like data (,) a b = (,) {fst :: a, snd :: b} Then the following would work: Prelude> let a = (1,2) Prelude> a {fst = 3} (3,2)

1 0

executable scripts?
by John Velman 24 Oct '04

24 Oct '04

One of the nice things about perl (for example) is that you can put together a script with #!/usr/local/perl (in bash for example) as the first line of a file and run it immediately. I've used perl a lot this way with simple 'throw away' scripts to do special filtering on a file, or some other processing that I want to do one or a few times. occasionally, a script like this will have a more permanant value to me, and I keep it around. Is there some way to do something similar in with Haskell? I've tried the most obvious (to me) test with Hugs and it doesn't work. Surely there is a way to do this! Thanks, John Velman

4 4

existential type problem
by Andrew Pimlott 23 Oct '04

23 Oct '04

I'm having trouble using an existential type, becasue of what seem to be limitations in how I can express the type. I want values in my existential type to denote, for some monad, a monadic operation and a way to run the monad. Except, I want it mix the operation with operations in another monad, so it use a monad transformer. Specifically: data Foo = forall t. (MonadTrans t) => Foo ((Monad m, Monad (t m)) => t m a -> m a) -- run ((Monad m, Monad (t m)) => t m Int) -- op prog :: Foo -> IO Int prog (Foo run op) = run $ do lift $ putStrLn "Running prog" op ghci gives the error Could not deduce (Monad (t IO)) from the context (MonadTrans t) arising from use of `op' at try.hs:22 Hmm.... I see that my constraints did not mean what I expected. As the "Probable fix" suggests, I can add Monad (t IO) to the existential context to make this code type check, but I want it to work for all monads, not just IO. Something like data Foo = forall t. (MonadTrans t, (forall m. Monad m => Monad (t m))) => Foo ... But I haven't found anything like that. I would also welcome other approaches to this problem. Andrew

3 6

Relational Algebra post
by Brian Beckman 22 Oct '04

22 Oct '04

on my blog (http://weblogs.asp.net/brianbec <http://weblogs.asp.net/brianbec> ) , i've posted a couple of Haskell gadgets. One is a simulator for the "relational algebra" of database theory. The other is just an expansion of one of Paul Hudak's derivations of State monads.

1 0