Development has been progressing well on fwrap, although the first release is still a month in the future, at the very least.
Since last summer, it became clear that the core of fwrap — the code that generates the fortran wrappers, the C and Cython headers and the cython wrappers — was inextricably tied into the syntax tree generated by fparser, in a bad way. Fwrap had to muck around too much in the guts of fparser’s classes to get stuff done. By the end of GSoC, fwrap was in a workable state (still not at first release, though), but it was very brittle and increasingly difficult to add functionality incrementally.
My efforts of late have been to extract fwrap from fparser, and fwrap’s core is in a better state. I’m finding it easier to add in the necessary functionality, and the overall architecture is easier to grasp and adapt. I want to make it tolerably easy for others to understand and contribute to the code-base, and keeping fwrap’s core separate from fparser shrinks the mental load considerably.
These are the main areas of functionality that I’m planning on addressing for the first release:
- All intrinsic datatypes (integer, real, double precision, complex, logical and character) wrapped end-to-end.
- Top-level functions & subroutines (those not inside a module) wrapped, end-to-end.
- Assumed shape arrays (declared with ‘integer, dimension(:,:) :: int_array’) wrapped, end-to-end.
- Explicit shape arrays with trivial expression extents (‘integer, dimension(d1, d2, d3) :: int_array’) wrapped, end-to-end. (Assumed-size arrays (‘dimension(d1, d2, *)’) are included here.)
- Automatic discovery and compilation of kind-type-parameter values. For instance, if a module has a parameter ‘SP’ defined and a subroutine uses that module’s parameter as a kind-type-parameter, fwrap will handle things automatically for you. This is mostly a parsing issue and one where fparser needs work.
- Older constructs, like common blocks & implicit typing, shouldn’t be too bad, either. Since common blocks map to C structs, these might wait until we get to derived-type support. We’ll see.
With the decoupling between fwrap and fparser, it will be possible to write by hand a ‘pyf’ interface file that gives fwrap all the necessary bits to make the right wrappers. This makes testing easier and further helps to decouple fwrap from fparser.
There are many more fortran features that fwrap will support, if I can get the time or attract other contributors. High on the list are function/subroutine arguments (done well), Python callbacks, and full module wrapping. Module wrapping has the possibility to be rather interesting, since it is possible to have a nice correspondance between Fortran 9x modules and Python extension types, so long as a few guidelines are adhered to on the Fortran side. The C binding features supported in all major fortran compilers makes this Fortran module -> Python extension type mapping possible. But that is far in the future. I should mention that Fortran derived types will be supported soon after the first release, as well.
So there’s an update for you — long on promises & ideas, but things are coming together nicely. Once the first release is out I’ll put more effort into publicizing things and facilitating contributions, including a more detailed roadmap.