Python/Fortran interoperability

[Paul van Delst]

On 24 Aug, 02:57, (e-mail address removed) (Richard Maine) wrote:

Does anyone use OOP in Fortran anyway?

I do - currently for learning (and eventually training) purposes so I don't distribute any
of the code. But, the fact that...

Fortran 2003 compilers are not ubiquitous.

....is a major sticking point towards a fully engaged f2003 programme (not program )

Fortran compilers tend to support a
subset for Fortran 2003, usually ISO C bindings but not OOP.

Yeah, I'm starting to find it a little bit tiresome that vendors now appear convinced that
implementing some of the more note-worthy features of f2008 is of greater importance that
wrapping up the f2003 implementations. But, it's their business for their customers so
c'est la vie I guess

If I ignore parameterised derived types then my f2003 platform/compiler of "choice", IBM
AIX xlf2003, works well for OOP stuff.

cheers,

paulv

 

[Kurt Smith]

You might want to ask also on the Cython, NumPy and SciPy mailing lists.
NumPy and SciPy have a rather large audience of scientific developers, and
Cython has a running sub-project on providing better Fortran integration
(which might be of interest to you anyway).

Thanks for the mention, Stefan. For those who are interested, here's
my blog summarizing the status of 'fwrap,' a Fortran wrapper utility
for the C, Cython & Python languages.

http://fortrancython.wordpress.com/

Linked there are my talk slides & presentation at last week's SciPy
2009 conference, which gives a good overview.

Kurt

 

[nmm1]

You also made this claim regarding Fortran's C interop with strings:

"No, I mean things like 'Kilroy was here'. Currently, Fortran's C
interoperability supports only strings of length 1, and you have
to kludge them up as arrays. That doesn't work very well, especially
for things like function results."

This obviosuly proves you wrong:

Er, no, it doesn't. I suggest that you read what I said more
carefully - and the Fortran standard. As I said, you can kludge
them up, and that is precisely one such kludge - but, as I also
said, it doesn't work very well.

However, I shall take your answer as a "yes, I want to do that".



Regards,
Nick Maclaren.

 

[sturlamolden]

This obviosuly proves you wrong:

Er, no, it doesn't.  I suggest that you read what I said more
carefully - and the Fortran standard.  As I said, you can kludge
them up, and that is precisely one such kludge -

You said we have to kludge them up as arrays. I did not. I kludged up
the C string as a pointer to a Fortran string, and called strlen to
get the length of the C string. You also said we can only interop with
length-1 character strings. My kludge was valid Fortran and works with
strings of any length up to some sane limit that you can specify.

You cannot expect a C pointer to carry information about the length of
the string. C strings are nul terminated, which is precisely why we
have strlen. When C has to use strlen to get the length of a C string,
so does Fortran. You cannot use the Fortran standard to change the
behaviour of C.

but, as I also
said, it doesn't work very well.

Only if you have an incredibly stupid compiler.


Sturla

 

[Richard Maine]

You also said we can only interop with
length-1 character strings. My kludge was valid Fortran and works with
strings of any length up to some sane limit that you can specify.

There might be a confusion here (and I'm not even sure on whose part) on
a picky but important detail of wording. I have seen multiple people
confused by this one before. In fact, some potential confusion was
forseen, which is why there are notes specifically about it in the
Fortran standard (see below). Those notes do tend to get overlooked
though.

Only character strings of length 1 are interoperable, as the term
"interoperable" is defined in the Fortran standard. However, that does
not mean that only character strings of length 1 will work with C. The
distinction might be picky, but it is important.

See Note 15.19 (which in turn cites an example in Note 15.23) of f2003.
You can pass a Fortran string of length n as an actual argument
corrseponding to a dummy argument that is an array of n character*1
elements. This isn't considered a question of "interoperability", as it
is a feature purely within Fortran, but it does impact on what kinds of
things work.

One might plausibly regard this as a kludge, but it is a kludge that is
part of the Fortran standard and is guaranteed to work with all Fortran
compilers. I almost said all f2003-compliant compilers (admittedly a
limited set), but then I recalled that the feature actually dates back
to f77 when character type was introduced; f2003 just extends it to the
C character kind for the obscure case where the C character kind might
be different from the default character kind (I don't know of any
compilers where this is so, but the standard allows for it).

 

[nmm1]

Only character strings of length 1 are interoperable, as the term
"interoperable" is defined in the Fortran standard. However, that does
not mean that only character strings of length 1 will work with C. The
distinction might be picky, but it is important.

Precisely. And the kludge does NOT work under all circumstances,
which is why I said that it doesn't work very well.

Consider, for example:

SUBROUTINE Fred (X) BIND(C)
CHARACTER*(*) :: X
END SUBROUTINE Fred

CHARACTER(LEN=100) :: string
CALL Fred(string(40:60))
CALL Fred(string(5:50))

This is not currently allowed and raises all sorts of 'interesting'
implementation and portability questions. For example, I defy anyone
to write Fred portably in C

It gets really hairy if you have functions that have assumed length
results, but those are obsolescent.

Even when Fred has an explicit length, there are some problematic
cases, which could catch out programmers in one language that don't
know the other fairly well. But those are much less of a problem
than the common need for assumed length CHARACTER arguments.


Regards,
Nick Maclaren.

 

[sturlamolden]

Precisely.  And the kludge does NOT work under all circumstances,
which is why I said that it doesn't work very well.

Do you have an example?

Consider, for example:

    SUBROUTINE Fred (X) BIND(C)
    CHARACTER*(*) :: X
    END SUBROUTINE Fred

Obviously that is not allowed, because C does not know anything about
Fortran strings. How should a C compiler pass the correct data
structure to Fred?

The C bindings in Fortran 2003 has functions to convert C pointers to
Fortran pointers (c_f_pointer, c_f_procpointer), because C does not
know the ABI of a particular Fortran implementation.

 

[glen herrmannsfeldt]

In comp.lang.fortran (e-mail address removed) wrote:
(snip)

< Precisely. And the kludge does NOT work under all circumstances,
< which is why I said that it doesn't work very well.

< Consider, for example:

< SUBROUTINE Fred (X) BIND(C)
< CHARACTER*(*) :: X
< END SUBROUTINE Fred

< CHARACTER(LEN=100) :: string
< CALL Fred(string(40:60))
< CALL Fred(string(5:50))

< This is not currently allowed and raises all sorts of 'interesting'
< implementation and portability questions. For example, I defy anyone
< to write Fred portably in C

You mean, how does FRED know the length? It seems to me the
usual question for Fortran assumed size arrays. Assuming that
FRED can tell from the passed string, it seems fine to me.
If not, it is a problem.

Null terminated strings are a C convention, supported by
the library and compiler (string constants). Others are legal C,
though you have to be careful which library routines you use.

< It gets really hairy if you have functions that have assumed length
< results, but those are obsolescent.

< Even when Fred has an explicit length, there are some problematic
< cases, which could catch out programmers in one language that don't
< know the other fairly well. But those are much less of a problem
< than the common need for assumed length CHARACTER arguments.

Maybe Fortran programmers who started in Fortran 66 will not
have so much problem with this. The usual way would be to
pass the length, as with assumed size arrays. I believe terminating
strings with unusual (likely not null) characters was also done.

-- glen

 

[nmm1]

Do you have an example?

I gave you one. Also see below.

Obviously that is not allowed, because C does not know anything about
Fortran strings. How should a C compiler pass the correct data
structure to Fred?

Precisely. The reason I asked that question is that it would be
possible to extend the standard to make it possible in a portable
fashion.

You might also like to consider the converse problem: how to write
a Fortran function that takes a C string of arbitrary length and
uses it.


Regards,
Nick Maclaren.

 

[nmm1]

< Consider, for example:

< SUBROUTINE Fred (X) BIND(C)
< CHARACTER*(*) :: X
< END SUBROUTINE Fred

< CHARACTER(LEN=100) :: string
< CALL Fred(string(40:60))
< CALL Fred(string(5:50))

< This is not currently allowed and raises all sorts of 'interesting'
< implementation and portability questions. For example, I defy anyone
< to write Fred portably in C

You mean, how does FRED know the length? It seems to me the
usual question for Fortran assumed size arrays. Assuming that
FRED can tell from the passed string, it seems fine to me.
If not, it is a problem.

Precisely. And the whole point of my question is how many people
WANT to do it, from the point of view of extending BIND(C).

< Even when Fred has an explicit length, there are some problematic
< cases, which could catch out programmers in one language that don't
< know the other fairly well. But those are much less of a problem
< than the common need for assumed length CHARACTER arguments.

Maybe Fortran programmers who started in Fortran 66 will not
have so much problem with this. The usual way would be to
pass the length, as with assumed size arrays. I believe terminating
strings with unusual (likely not null) characters was also done.

Yeah. But there are a decreasing number of us left

Prefix length strings were also used.


Regards,
Nick Maclaren.

 

[sturlamolden]

You might also like to consider the converse problem: how to write
a Fortran function that takes a C string of arbitrary length and
uses it.

That's what the code I showed you does.

 

[James Van Buskirk]

There might be a confusion here (and I'm not even sure on whose part) on
a picky but important detail of wording. I have seen multiple people
confused by this one before. In fact, some potential confusion was
forseen, which is why there are notes specifically about it in the
Fortran standard (see below). Those notes do tend to get overlooked
though.

Only character strings of length 1 are interoperable, as the term
"interoperable" is defined in the Fortran standard. However, that does
not mean that only character strings of length 1 will work with C. The
distinction might be picky, but it is important.

See Note 15.19 (which in turn cites an example in Note 15.23) of f2003.
You can pass a Fortran string of length n as an actual argument
corrseponding to a dummy argument that is an array of n character*1
elements. This isn't considered a question of "interoperability", as it
is a feature purely within Fortran, but it does impact on what kinds of
things work.

One might plausibly regard this as a kludge, but it is a kludge that is
part of the Fortran standard and is guaranteed to work with all Fortran
compilers. I almost said all f2003-compliant compilers (admittedly a
limited set), but then I recalled that the feature actually dates back
to f77 when character type was introduced; f2003 just extends it to the
C character kind for the obscure case where the C character kind might
be different from the default character kind (I don't know of any
compilers where this is so, but the standard allows for it).

No, this is a tricky point. It was allowed in f77 to pass an array
actual argument to a scalar character dummy argument, but the ability
to pass a scalar character actual argument to an array dummy argument
is new to the sequence association rules of f2003. So your first
impression was more accurate than the result of thoughtful reflection

 

[Richard Maine]

No, this is a tricky point. It was allowed in f77 to pass an array
actual argument to a scalar character dummy argument, but the ability
to pass a scalar character actual argument to an array dummy argument
is new to the sequence association rules of f2003. So your first
impression was more accurate than the result of thoughtful reflection

Ah. You might be right - probably you are. I know there is some closely
related stuff that goes back a ways and was just extended to the C
character kind in f2003, but it might not have been that exact bit. I'm
probably thinking of the rule for sequence association that allows the
character length parameter to differ between the actual and dummy... as
long as you are doing sequence association. But it might be a new rule
that puts the scalar case under sequence association; that's probably
it. Not worth dragging out the standards to check, but I bet that's it.