Have all you taken into account the ISO_C_BINDING stuff from Fortran 2003 standard?
On Tue, Mar 24, 2009 at 5:42 PM, Robert Bradshaw <[email protected]> wrote: > 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 > -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
