On Mar 24, 2009, at 7:32 AM, Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: >> Dag Sverre Seljebotn wrote: >> >>> Is it OK to have nice and convenient wrapping of Fortran >>> libraries as an >>> additional feature of core Cython? >>> >>> [ ] Yes, that would be grand >>> [ ] No, that would bloat the language and/or the compiler/ >>> project too >>> much, I'd prefer to see this in a standalone tool/plugin >>> >> >> [X] It depends on how it's done. >> > OK, some details then. This is a scetch only!
Given these details (though there's still a lot to hammer out), I'd vote [X] Yes, that would be grand as well. > First of all, this is about calling into Fortran (i.e. calling > conventions) only, not about writing Fortran code using Cython. > > 1) A "fortran" calling convention on external function > declarations, and > perhaps a "module"/"namespace" declaration (which one could reuse > for C++): > > cdef extern: > module mymodule: # reusable for C++ wrapping, could say > "namespace" > instead > cdef fortran sometype myfunc(sometype arg) I like the cdef extern from fortran module "mymodule" syntax (as well as cdef extern from "cppheader.H" namespace "mynamespace"). > When "fortran" is in effect, one may accept some extra syntax for the > arguments, i.e. "in" or "inout" (but "const" and no const could serve > the same purpose). I'll let people who are more familiar with this hash it out, but if it's semantically different than const, lets not overload (especially since we don't even support the standard const yet). > 2) Types -- I am thinking of a "cython.fortran" psuedomodule with > Fortran types (i.e. cython.fortran.real(kind=8)); these would > simply map > down to C typedefs. But one could get by with a simple pxd with no > compiler support as well. +1 > 3) Potentially parsing of Fortran files to autogenerate pxd files, but > this could be a seperate tool and/or be pluggable using an API that > could also be used for header files. Yes. I could see us shipping a set of header -> pxd scripts. Actually, ran across one for .h files already. > Implementation-wise, there would be a transform which would deal with > calls to functions using the Fortran calling convention, and > generates a > mymodule.f90 wrapper to supplement mymodule.c -- however this is a > very > thin wrapper to retype the Fortran functions from Fortran-side to use > some C conventions and some Cython-specific conventions, and most > of the > things would be C-side. > > The argument for doing this in Cython is that both Cython/Python and > Fortran support a higher-level construct which C doesn't > (buffers/strided arrays). > > How does that make you feel? Alternatives: > - Plug it in through a plugin framework > - Do it through a preprocessing step which generates the > necesarry .pyx > and .f90 files. I think it makes the most sense to have a .f90 file correspond to the library .pxd file (either generated from the .pxd, or along side the .pxd), but I don't have much experience with fortran. If two separate .pyx files use the same library, how (if at all) would their .f90 wrappers differ? Also, what would the compilation process then be like? - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
