
Hi Bulat! On Aug 24, 2006, at 1:17 PM, Bulat Ziganshin wrote:
Hello Gregory,
Thursday, August 24, 2006, 7:29:47 PM, you wrote:
it seems that unsafeIOToST is safe in this case, in the sense that
why you are stuck to ST monad? isn't it better to use just IO monad?
The IO monad may be more appropriate. The simulation evolved out of a different (and simpler) simulate for a 6502 microcontroller which used the ST monad. I had thought at the time that there may be multiple threads in the full simulation, so using state threads seemed a good idea at the time. (The full simulation may still need multiple threads; I don't know yet.) As it stands, the code I had written was almost correct. I needed a lazy version of the WriterT monad to make it work. Chris Kuklewicz pointed this out to me. The toy model now works with both the lazy WriterT (called LogT here) and the unsafe* operation. Some performance data: using unsafeIOToST to write log messages directly to the output, the simulation does 10^7 state updates in about 45 seconds on my 1.5 GHz ppc G4. Using LogT, with a list of strings as the monoid, it takes about 7 minutes to do the same, and the system swaps heavily during the last few minutes. Not surprising, given that the mappend operation is not very efficient for the list monoid. Is there a simple monoid structure I could use instead of a list to generate the log string incrementally? I don't care if the order of the output is reversed.
and about total style - again, you can use my lib or write this yourself so that all you reference operations will work independent on Monad used and you can freely experiment with different monads without rewriting whole code:
class Ref m r | m->r where newRef readRef writeRef
instance Ref IO IORef writeRef r x = writeIORef r $! x
instance (Ref m r) => Ref (WriterT m) r where writeRef = lift . writeRef
and so on...
The code snippet above looks like a very good idea. The monad dependent operations combined with "lift" seem more complicated than necessary. "lift" in particular often seems like plumbing that should not be necessary. Best Wishes, Greg
ps to Brian: it is why i was so interested in your idea. writing monad-independent code, including code that can be applied to any monad lifted from ST or IO, looks for me very promising idea, somewhat that will be widely used in future
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe