[Haskell-cafe] Sequencing Operations in a Monad

SevenThunders mattcbro at earthlink.net
Fri Sep 21 12:17:17 EDT 2007

Al Falloon wrote:
> SevenThunders wrote:
>> Well it certainly requires some thought here.  As I see it, I now have
>> two
>> reasonable choices.  Either I pull all my matrix operations back inside
>> the
>> IO monad and avoid the matrix action as a matrix variable paradigm  (due
>> to
>> the loss of referential transparency)  or I devise some way to guarantee
>> 'safety' and use unsafePerformIO.  I suppose I can use a somewhat
>> generalized version of safety where if I can guarantee that the order of
>> operations doesn't matter to the final output then I'm OK.  In this case
>> if
>> I can make it so that reording the computations only reorders the
>> locations
>> of my matrices on the stack, but otherwise doesn't affect the contents of
>> the matrices I think I am golden. 
>> I believe I got burned by following a nice tutorial interpretation of the
>> IO
>> monad as a way of carrying around an undeclared state variable,  the
>> world. 
>> But my little matrix IO variable is not just a world state with some
>> matrix
>> data in it, rather it appears to be a world state with a chain of
>> unapplied
>> function evaluations.  This is due to laziness I believe.  If I had a
>> data
>> structure that looked more like a world state with a reference to a
>> variable
>> in that world state, I could find a way to achieve my goals I think.
> I know that you have already made your decision and moved on, but I 
> think that there is still another alternative that you can consider: 
> make an abstract interpreter for your matrix operations.
> The basic idea is to use the normal Num et. al. type classes to write 
> your matrix calculations. However, instead of actually performing the 
> calculations it instead builds a data structure that represents the 
> calculations. You then 'interpret' the data structure in a separate 
> function in the IO monad.
> The advantage of the approach is that you can pre-process the abstract 
> data structure to recognize intermediate matrices that can be consumed 
> without copying and other optimizations.
> The other advantage is that the matrix math itself doesn't need to be in 
> the IO monad, only the interpretation, so you can use all the functional 
> goodness when writing the matrix operations.
> I was going to whip up a small example, but I am pressed for time. So 
> here is a post from Oleg that shows the idea. 
> http://www.haskell.org/pipermail/haskell/2007-January/019012.html
> As usual his post is mind-expanding and probably a bit of overkill for 
> your problem, but I was the best I could come up with, google was not my 
> friend. You might have better luck (try "higher order abstract syntax" 
> and "abstract interpretation" and go from there)
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

That's an interesting approach.  However if performance is a main concern
(in addition to 'elegance'), I would be concerned about having an
interpreter in an inner loop of some operation.  I quite frequently write
functions that do hundreds of matrix multiplies using hundreds of different
indexed matrices, where the function iterates over the matrix index.

When I first designed my Matrix library and was interfacing it with Haskell,
I considered the possibility of actually using Haskell to compile my
computations into C.  Thus there would be a matrix data type in Haskell, but
the final output of the Haskell operations would be C code.  In retrospect
that would have had a number of advantages, perhaps both in performance and
interoperability with the 'normal' programming world.  However I also wanted
to take advantage of ghci so that I could interact with my code in real
time.  That too is probably possible with the current toolset, but it would
have taken somewhat longer to develop.
View this message in context: http://www.nabble.com/Sequencing-Operations-in-a-Monad-tf4446047.html#a12824919
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

More information about the Haskell-Cafe mailing list