Jed, the interface has multiple layers. At the lowest, I'm using inline-c (e.g. https://www.fpcomplete.com/blog/2015/05/inline-c ), and so far got basic functionality up to KSP up and running by wrapping the individual PETSc calls as "arrows" , and composing in IO for which there are a number of bracketing constructs also for handling exceptions. (mapping error codes to these is another daunting task for later; for now I let the petsc stderr do all the signaling)
Two type signatures as example: kspCreate :: Comm -> IO KSP, withKSP :: Comm -> (KSP -> IO a) -> IO a which also require representing Vec, Mat, KSP etc. as opaque datatypes with abstract Storable instances. (type alignment courtesy of inline-c) (so: no need for copying data back to memory, during normal operation of the library) I was asking about the Viewer for e.g. Vecs and Mats to hook up e.g. with plotting functionality on the Hs side, but since this would be needed "offline", I might just dump to file and load from there. As you say, the mutating operations are a tough cookie to represent functionally. There are a number of choices for representing state propagation though, and I'm presently looking into a few. Thank you, Marco On 17 July 2015 at 19:28, Jed Brown <[email protected]> wrote: > Marco Zocca <[email protected]> writes: > >> Dear PETSc, >> in writing the foreign-function wrappers for the library in Haskell, >> I found the need for an operation that copies the contents of a Mat or >> Vec, > > I think this is actually not great design for an FFI to an object > library like PETSc. The interface strategy you seem to be modeling your > approach after is designed for libraries that operate on raw arrays with > no encapsulation instead of objects. > > A critical question is what to do about mutability. Haskell likes > functional data structures which typically have at least a "lazy spine" > and thus the new objects that you are constantly creating can share the > heavier parts. Though some PETSc objects (like IS) are effectively > immutable, objects like matrices and Krylov solvers are mutated in-place > (MatSetValues and per-iteration recurrences and diagnostics). > > Also, distributed memory systems have famously different failure > semantics than non-distributed systems. > > For these reasons, I think it will be challenging to write a nice > functional interface to PETSc. The obvious thing is to put it in a > monad, but I think that would be a desperately hard sell for other > Haskell users.
