Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> Dag Sverre Seljebotn wrote:
>>
>>> 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)
>>>
>>
>> Fine with me. What about
>>
>> cdef extern from "myheader.h":
>>
>> for C and
>>
>> cdef extern from module "mymodule":
>>
>> for Fortran and
>>
>> cdef extern from namespace "mynamespace":
>>
>> for C++, which would automatically enable C, C++ and Fortran conventions
>> for their body? (i.e. without a "fortran" or "module" keyword).
>>
> Comments: I like the explicitness of the "fortran" keyword, and C++
> requires a header file to be included as well as a namespace.
cdef extern from fortran module "mymodule":
cdef extern from "cppheader.H" namespace "mynamespace":
? I'd really like to keep the syntax simple here. You will never have
anything but Fortran conventions in a Fortran module, so requiring a
sub-block complicates things unnecessarily.
>>> 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'm for using in/inout (maybe as a Py3 annotation or whatever) rather
>> than overloading "const".
>>
> Actually, I slipped here. Pointers would be "inout", i.e.
>
> cdef fortran void myfunc(int* foo) # foo is inout argument
>
> I would *not* like to have Cython code where "myfunc(x)" can change the
> value of x :-)
>
> But for array/buffer arguments, "in"/"out"/"inout" would be nice to have.
In that case, could they be declared as part of the array/buffer
declaration (inside the []), instead of becoming an external part of the
variable declaration?
>>> 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.
>>
>> Wouldn't the external .pxd generator tool be the right place to also
>> generate the .f90 wrapper? I don't see Cython generate a Fortran module
>> while compiling a Cython module to C code that *calls* the module.
>>
> I was hoping to do this without ever touching Fortran parsing at first,
> the way one does it with wrapping C. This would loose the possibility of
> working from a manually written pxd at first.
Why would you write a .pxd by hand if you can just run a little tool on
your Fortran module? :-)
That said, generating the .f90 module from the .pxd should be no different
from generating it from the .pyx sources, right? So it doesn't matter
where you get your .pxd from.
The only question is what generates the F90 wrapper, and I don't think
it's the compiler that compiles the Cython sources. In most use cases I
can see, you will generate the wrapper once (or once in a while), but your
Cython code many, many times during development. So this really is a
different tool that generates different code (from the same .pxd file).
> Also the f90 wrapper would insert Cython-specific structs in the call
> signature to marshal PEP-3118 buffers across.
How is that something that must be done during the compilation of the
*calling* code? It's the *called* code that is affected here.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
