David F. Place wrote: > > > On Jul 23, 2006, at 1:20 AM, Matthew Bromberg wrote: > >> I do want to understand the advantages of Haskell. My approach has >> been to consign the heavy imperative, state manipulating code to C >> and leave the higher end stuff to Haskell. The nature of my >> problem (a simulation) necessitates holding state for efficiency >> reasons. (e.g. I don't want to copy a 500 MB matrix every time I >> change an entry.) I assumed that Haskell would be easier to write >> and perhaps maintain than the horrors of pure C. At this point >> there is no turning back. I will probably answer this question soon >> enough. >> > > Hi Matthew, > > It seems that a lot of your issues stem from the design decision to > implement a good chunk of your program in C. There are certainly > ways to implement an indexed data-structure in Haskell with good > performance for persistent functional updates. Alternatively, you > could write imperative code in Haskell to update the array in place > non-persistently. So, the decision not to use Haskell for that part > may be a case of premature optimization. > > Cheers, David > > -------------------------------- > David F. Place > mailto:[EMAIL PROTECTED] > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
You make a good point and the decision was by no means cut and dry. However I made a point of developing some test code using some the newer array data types and looked at maintaining the array in Haskell and then directly calling Blas etc. I even had a nice polymorphic matrix class going. However I found the array interface just a bit too 'clunky' to use a technical term. The withArray interface is not very appealing. The layers of lambda notation was giving me a headache. The idea of separating the imperative code into an imperative language was appealing to me. Moreover using a stack based architecture for matrix operations makes the C end of things very easy to implement. The big bugaboo of memory management issues pretty much disappears, and thinking of the world state in the IO monad as a stack of matrices has a nice intuitive appeal for me. It seems to work well so far as I said earlier. I'm not sure all my issues would have gone away if I had tried to do more of the matrix op.s in Haskell. It is pretty much a given that I need to interface to external optimized libraries, that's where the big number crunching is occuring and those libraries have had teams of Ph.D.s working on them for years. I want to leverage that. My approach actually minimizes the amount of marshalling I have to do between C and Haskell. The stack manipulations are simply scripted in a do clause, with nary an argument being passed. -- View this message in context: http://www.nabble.com/Why-Haskell--tf1986013.html#a5458965 Sent from the Haskell - Haskell-Cafe forum at Nabble.com. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
