Reorganize project

[bkaestner]

First of all, thanks for writing this bindings. That's kind of the project I always wanted to start, but never had the time. However, there are some things I'm wary of.

There's little documentation. This will be fixed over time, I guess. However, given that it's not really clear what all those t* in TestMain actually test, one has to carefully read all code (and be very familiar with PETSc).

The files feel like a playground. There are several lines of code commented out. There's no explanation why they're commented out. Future tests? Future functionality? Or current defunct tests due to missing functionality?

The structure isn't clear. Why is there an example main in TaoBlackScholes? Why are there several TestMain files? Why is there an Internal2? Where is Internal1? Was this pre-VC? Does this conclude that a contributor should write an Internal3?

Those problems (will) make it hard to contribute to the project. I suggest the following steps:

• [x] Remove old code. If you need it, it's still in the old git revision (better add a git-tag before committing changes).
• [x] Add intention of each module to the head of the module. This will help contributors to find the right place for their work (full documentation would be even better, but that will take time).
• [x] Fix #2, so that one can use the library in GHCi
• [x] Move tests and examples in new folders, /example and /tests. They aren't part of the bindings.

This steps can be done in any order and should make it easier to find contributors.

[ocramz]

Hi Benjamin, thank you for all these observations; yes, it's still a bit of a playground because I'm not sure myself of a number of things, e.g. an effective way to represent mutable vectors, however the hierarchy of files is already more or less defined.

After figuring out the interface to Vec and Mat data (see e.g. vecGetArray and vecRestoreArray in InlineC.hs and PutGet.hs) (I think I'll take inspiration from HNetCDF ) I'll remove all the old code and add at least the modules' intention.

Regarding your third point, you can already use it interactively from within GHCi; however the inline-c authors warn us about an incompatibility with cabal-repl; haven't had the time to properly investigate it. Marco

[bkaestner]

e.g. an effective way to represent mutable vectors

I guess you want to represent the foreign vectors from PETSc (Vec and Mat), otherwise an interface close to Data.Vector.Unboxed.Mutable or Data.Vector.Storable.Mutable comes to mind.

Regarding your third point, you can already use it interactively from within GHCi;

This was more or less meant for the the fourth point, e.g. together with cabal sandbox and cabal install and examples in /example:

$ cabal sandbox init
$ cabal install
...
$ cabal repl
ghci> :l examples/SVD.hs
showSVD $ toMat [[1,2,3],[4,5,6],[7,8,9]]

Also, I'm currently on Windows only, so I couldn't try it yet :(.

[ocramz]

2 is still open but the other points are improved upon; I'll close this for now. Stay in touch @bkaestner , and thanks for the input!