Starting point for a modern fortran module

[rikardn]

This is a starting point for modern fortran bindings for symengine

The module is in symengine.f08 and a small test program is in test.f08. It at least needs Fortran 2003. To build I have used:

g++ -c symengine.f08
g++ -c test.f08
g++ test.o symengine.o /home/symengine/build/symengine/libsymengine.a /home//symengine/build/symengine/utilities/teuchos/libteuchos.a -lgfortran -lgmp -lbfd -otest

It implements parse, Basic, Integer and Symbol a str-method and overloading of arithmetic operators.

The implementation is using the object oriented features and the iso_c_binding module of Fortran 2003. Binding to the symengine cwrapper. It focuses on giving as native Fortran feel of the interface as possible.

[rikardn]

Sorry for not integrating with the cwrapper module in #5. I didn't see it at first.

[ivan-pi]

Hey @rikardn, not integrating with #5 is really not a problem as it is not 100 percent ready. Does your PR use any of the same low-level C interfaces? I can try polishing those.

[certik]

@rikardn thank you for this!

@ivan-pi I added you to push access so that you can help with development of this.

I am on travel, but I will try to test this out soon.

[rikardn]

@ivan-pi Yes, I am using the same low-level C interfaces in the interface section of the module. I prefixed the functions c_, which might be unnecessary. I was afraid of name clashes in the linking. Then the methods and overloaded operators use the low-level C functions, but converts inputs and outputs to nicer Fortran types.

We could provide both interfaces in separate modules. One low level module with only the C interfaces and one module with object oriented features using the lower level interface module. Perhaps #5 could be merged (even if not 100% done) and then it would be easier to rebase #6 (together with potential changes) on top.

As a side note: I am using the trick outlined here to avoid memory leaks for temporary objects https://www.researchgate.net/publication/255677530_Avoiding_memory_leaks_with_derived_types

[certik]

As a side note: I am using the trick outlined here to avoid memory leaks for temporary objects https://www.researchgate.net/publication/255677530_Avoiding_memory_leaks_with_derived_types

This article is written by @arjenmarkus, he will be happy to see his article being used.

[rikardn]

Thanks @arjenmarkus for the excellent article! I spent several hours of debugging the memory leak until I found and was saved by your article.

[ivan-pi]

There was a follow up article to the one by @arjenmarkus,

Stewart, G. W. (2003, December). Memory leaks in derived types revisited. In ACM SIGPLAN Fortran Forum (Vol. 22, No. 3, pp. 25-27). New York, NY, USA: ACM.

It can be downloaded here. It covers the problem of nested subprogram invocation.

[rikardn]

Thanks @ivan-pi for the follow up. I'll see if the issue can be reproduced with these bindings. In that case we'll need to try the same trick. Stewart also talks about this potentially being solved in Fortran 2000 (meaning Fortran 2003 I guess).

[rikardn]

Given the example in the paper by Stewart I tested the following program using the module in this PR:

subroutine foo(x, y)
    use symengine
    type(basic), intent(in) :: x
    type(basic), intent(inout) :: y
    y = x
    y = x + y
end subroutine

subroutine dostuff()
    use symengine
    type(Basic) :: a, b

    a = SymInteger(28)
    call foo(a, b)
    print *, b%str()
end subroutine

program test
    implicit none
    call dostuff
end program

When running this I cannot see any memory leak. I am linking with a debug compiled version of symengine and with the previous problem I got direct printouts of symengine objects that wasn't freed correctly, but not in this case. Perhaps this isn't a problem any longer.

[certik]

Looks great. Ironically, I never use OO in Fortran, but this would be the first example where I would use OO, to ensure memory safety and reasonable syntax.

@rikardn how do you want to move forward? I am happy for you to merge this and go from there, or whatever else you want to do.

[rikardn]

Thanks @certik. After merging this the following needs to be done

1. Integrate with cwrapper module [WIP] #5
2. Use build system to build the module
3. Unit tests (perhaps test.f08 can be transformed into unit tests)
4. Add more functionality to the OO interface

I would like to work on 4 and potentially 1 and 3.

[certik]

@rikardn if you are ready, go ahead and merge this.

[rikardn]

@certik could you please give permissions to this repo (symengine.f90) for the push-access team? Otherwise I will not be able merge.

[certik]

Done! Can you merge now?

[rikardn]

No, I still cannot. The permissions for the team is set to read for this repo.

[isuruf]

Fixed

[certik]

Sorry about that. Try now.

[rikardn]

Thanks! Now it works.