[Haskell-cafe] Design and state...

[Magnus Therning]

Recently I've been hacking together a small Haskell module on top of
ptrace(2).  It's comming along nicely, but it's very low level.  The
signals arrive in a list:

  wait :: Int -> IO [Signal]

and processing of the signals can be done using e.g. mapM_:

  wait childPid >>= mapM_ processSignal

In a few cases this low level requires quite a bit of extra code.  Code
needs to be repeated in every program using the module.  Dealing with
breakpoints is a good example:

 - Setting a breakpoint requires storing the old instruction at the
   address
 - When hitting a breakpoint the old instruction should be put back, EIP
   backed up, perform one single-step, and last put the breakpoint back
   again.

I believe adding another layer on top of what I have now seems like a
good idea.  AFAICS that means having a state (I must keep track of the
original instruction).  That can easily be done by wrapping IO in a
StateT:

  forEachSignal:: Int -> (Signal -> IO ()) -> StateT DbgEnv IO ()
  forEachSignal childPid procSignal = ...

(Or would it be better using IORefs and "OO" in the way described in "IO
Inside"[1]?)

What I am struggling with is how to allow the user of the module to have
state as well.  I can see how "OO"[1] can be used to solve it, but is
there a more elegant, maybe more idiomatic (Haskellic??), way?

Or am I missing a more elegant way of dealing with this?

/M

[1]:
http://haskell.org/haskellwiki/IO_inside#Example:_emulating_OOP_with_record_types

-- 
Magnus Therning                             (OpenPGP: 0xAB4DFBA4)
magnus at therning.org             Jabber: magnus.therning at gmail.com
http://therning.org/magnus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20070321/5664eaf7/attachment.bin