October 2004 - Haskell-Cafe

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 23 Oct '04

23 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

Stream processors
by Peter Simons 21 Oct '04

21 Oct '04

Hi, I have run across the following idiom several times in the last few weeks: Some part of my program reads input from a 'Handle' and repeatedly calls a "stream processor" to incrementally compute some result, say an SHA1 hash, for example. All my stream processors can be reduced to the following interface: import Foreign ( Ptr, Word8 ) type Buffer = (Ptr Word8, Int) data StreamProc ctx a = SP { start :: IO ctx , feed :: ctx -> Buffer -> IO ctx , commit :: ctx -> IO a } I have to initialize some SP-specific context, then I can feed the data into a stateful computation as it comes in, and after receiving EOF I finalize the SP to obtain the result I wanted. The StreamProc interface works nicely for all kind of things, be it message digests, encryption, encoding, or parsers. And obviously, it's a rather generic concept. One that doesn't have to be re-invented every time ... Which leads to my question: Is there any generic module available that implements such a SP? Or something similar? I know the stream processors as described in Hughes' paper about Arrows, but those are pure stream processors -- they don't allow for I/O, which I need to handle the Ptr. Does anyone have a recommendation for me? Peter

4 11

Re: [Haskell-cafe] Re: Stream processors
by MR K P SCHUPKE 21 Oct '04

21 Oct '04

>No, my stream processors currently have the API I described My point was... using the IO library I posted which abstracts the buffer management, you can treat the IO as a simple list... so you don't need to manage the buffers as such and you can use a simple stream processor like: > process :: [a] -> [a] But of course you have to use the List class operators so that would become: process:: List l a => l a -> l a Keean.

2 1

Re: [Haskell-cafe] Re: Stream processors
by MR K P SCHUPKE 21 Oct '04

21 Oct '04

Okay, maybe I misunderstood, I thought by stream processors you meant functions of the type: process :: [a] -> [a] where both the input and the output are lazy lists (streams) I would assume if you want to have a stateful filter you need to maintain the state by using either: process :: [a] -> IO [a] process :: <state> -> [a] -> [a] process :: [a] -> ST s [a] Keean.

2 1