[Haskell-cafe] Sequencing Operations in a Monad

[SevenThunders]

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.