Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What constitutes idiomatic Fortran? #12

Open
rouson opened this issue Jan 21, 2016 · 12 comments
Open

What constitutes idiomatic Fortran? #12

rouson opened this issue Jan 21, 2016 · 12 comments
Labels

Comments

@rouson
Copy link
Collaborator

rouson commented Jan 21, 2016

I recently used the term "Fortran idioms" or possibly "idiomatic Fortran" on comp.lang.fortran and someone commented that they weren't sure such a thing exists, which makes me think that it should exist if it doesn't. I see the term "idiom" in discussions of common practices in other languages. I interpret it as being the common way one does things when she really knows the language's full range of capabilities and chooses the most powerful or succinct or transparent and expressive way to accomplish the goal. By comparison, there's a whole book on writing idiomatic Python.

I think of idiomatic Fortran as using things such as array constructors to do in one line what would require a loop in some other languages:

real, allocatable :: positive_integers(:)
positive_integers = [(i,i=1,100)]

Is there such a thing as idiomatic Fortran?

Would it be another reasonable name for "Best Practices"?

Are there other examples of practices you would consider to be natural idioms that an experienced Fortran programmer might use, but that a newcomer to the language -- especially one whose primary experience is in one of the other common scientific programming languages -- would likely do in a less elegant way?

Damian

@cmacmackin
Copy link
Collaborator

Well, the obvious one would be operations on entire arrays. Another would
be using an interface to overload the constructor for a derived type.
On 21 Jan 2016 08:18, "Damian Rouson" [email protected] wrote:

I recently used the term "Fortran idioms" or possibly "idiomatic Fortran"
on comp.lang.fortran and someone commented that they weren't sure such a
thing exists, which makes me think that it should exist if it doesn't. I
see the term "idiom" in discussions of common practices in other languages.
I interpret it as being the common way one does things when she really
knows the language's full range of capabilities and chooses the most
powerful or succinct or transparent and expressive way to accomplish the
goal. By comparison, there's a whole book on writing idiomatic Python
https://www.jeffknupp.com/writing-idiomatic-python-ebook/.

I think of idiomatic Fortran as using things such as array constructors to
do in one line what would require a loop in some other languages:

real, allocatable :: positive_integers(:)
positive_integers = [(i,i=1,100)]

Is there such a thing as idiomatic Fortran?

Would it be another reasonable name for "Best Practices"?

Are there other examples of practices you would consider to be natural
idioms that an experienced Fortran programmer might use, but that a
newcomer to the language -- especially one whose primary experience is in
one of the other common scientific programming languages -- would likely do
in a less elegant way?

Damian


Reply to this email directly or view it on GitHub
#12.

@szaghi
Copy link
Member

szaghi commented Jan 21, 2016

@rouson Great discussion! 👏

@cmacmackin I have experienced some problems overloading derived type name with Intel Fortran, see this. Do you have similar issues?

@cmacmackin
Copy link
Collaborator

@szaghi I haven't used ifort extensively enough to be able to say.

On 21/01/16 09:09, Stefano Zaghi wrote:

@rouson https://github.com/rouson Great discussion! 👏

@cmacmackin https://github.com/cmacmackin I have experienced some
problems overloading derived type name with Intel Fortran, see this
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/583935#comment-1835466.
Do you have similar issues?


Reply to this email directly or view it on GitHub
#12 (comment).

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io

@tclune
Copy link
Collaborator

tclune commented Jan 21, 2016

Yes - there have been issues with overloading structure constructors in ifort. Many have been fixed, but I believe I’ve still seen at least one case with version 16. The usual symptom is that some higher level procedure will generate an error indicating that the compiler thinks the constructor is the type or vice versa.

Often reordering the USE statements can get around this symptom. But in many instances I’ve had to go back and rename the constructor. Usually something like “newFoo” to make the intent clear.

  • Tom

On Jan 21, 2016, at 4:22 AM, Chris MacMackin [email protected] wrote:

@szaghi I haven't used ifort extensively enough to be able to say.

On 21/01/16 09:09, Stefano Zaghi wrote:

@rouson https://github.com/rouson Great discussion! 👏

@cmacmackin https://github.com/cmacmackin I have experienced some
problems overloading derived type name with Intel Fortran, see this
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/583935#comment-1835466.
Do you have similar issues?


Reply to this email directly or view it on GitHub
#12 (comment).

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io

Reply to this email directly or view it on GitHub #12 (comment).

Thomas Clune, Ph. D. [email protected]
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635

@szaghi
Copy link
Member

szaghi commented Jan 21, 2016

@tclune Thanks for your support!

@tclune
Copy link
Collaborator

tclune commented Jan 21, 2016

Unfortunately, the first thing that occurs to me as idiomatic Fortran are the consistent bad practices that are used throughout the community. E.g., using short variable names, long procedures, etc. Sad but true.

On Jan 21, 2016, at 3:18 AM, Damian Rouson [email protected] wrote:

I recently used the term "Fortran idioms" or possibly "idiomatic Fortran" on comp.lang.fortran and someone commented that they weren't sure such a thing exists, which makes me think that it should exist if it doesn't. I see the term "idiom" in discussions of common practices in other languages. I interpret it as being the common way one does things when she really knows the language's full range of capabilities and chooses the most powerful or succinct or transparent and expressive way to accomplish the goal. By comparison, there's a whole book on writing idiomatic Python https://www.jeffknupp.com/writing-idiomatic-python-ebook/.

I think of idiomatic Fortran as using things such as array constructors to do in one line what would require a loop in some other languages:

real, allocatable :: positive_integers(:)
positive_integers = [(i,i=1,100)]

Is there such a thing as idiomatic Fortran?

Would it be another reasonable name for "Best Practices"?

Are there other examples of practices you would consider to be natural idioms that an experienced Fortran programmer might use, but that a newcomer to the language -- especially one whose primary experience is in one of the other common scientific programming languages -- would likely do in a less elegant way?

Damian


Reply to this email directly or view it on GitHub #12.

Thomas Clune, Ph. D. [email protected]
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635

@milancurcic
Copy link
Collaborator

I suggest that from here on we refer to idiomatic Fortran code as being simply fortranic! 😄

@rouson
Copy link
Collaborator Author

rouson commented Jan 22, 2016

👏

@szaghi
Copy link
Member

szaghi commented Jan 22, 2016

😄
👏
👍

@tclune
Copy link
Collaborator

tclune commented Jan 22, 2016

Never mind. I spelled “ISO_FORTRAN_ENV” as “ISO_C_BINDING” and got unlucky that the first error was for INT16.

Getting some caffeine …

On Jan 21, 2016, at 7:56 AM, Tom Clune [email protected] wrote:

Yes - there have been issues with overloading structure constructors in ifort. Many have been fixed, but I believe I’ve still seen at least one case with version 16. The usual symptom is that some higher level procedure will generate an error indicating that the compiler thinks the constructor is the type or vice versa.

Often reordering the USE statements can get around this symptom. But in many instances I’ve had to go back and rename the constructor. Usually something like “newFoo” to make the intent clear.

  • Tom

On Jan 21, 2016, at 4:22 AM, Chris MacMackin <[email protected] mailto:[email protected]> wrote:

@szaghi I haven't used ifort extensively enough to be able to say.

On 21/01/16 09:09, Stefano Zaghi wrote:

@rouson <https://github.com/rouson https://github.com/rouson> Great discussion! 👏

@cmacmackin <https://github.com/cmacmackin https://github.com/cmacmackin> I have experienced some
problems overloading derived type name with Intel Fortran, see this
<https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/583935#comment-1835466 https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/583935#comment-1835466>.
Do you have similar issues?


Reply to this email directly or view it on GitHub
<#12 (comment) #12 (comment)>.

Chris MacMackin
cmacmackin.github.io <http://cmacmackin.github.io http://cmacmackin.github.io/>

Reply to this email directly or view it on GitHub #12 (comment).

Thomas Clune, Ph. D. <[email protected] mailto:[email protected]>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635

Thomas Clune, Ph. D. [email protected]
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635

@Tobychev
Copy link
Collaborator

In my experience "ideomatic lang" was something I first heard about python, and the usage of the word is mainly found there.

For that language the concept is a result of active and centralized work with style guides and I etiquette, and I think this is a way of handling the freedom the language allows.

For instance, many things in python are enforced by convention rather than by the specification/reference implementation; private methods are made private by name wrangling and filtering of the interpreter rather than by actual enforcement of privacy.

Fortran was created before there where language style guides, and does not have any natural centre that can impose a style upon the followers in the same way that python has the benevolent dictator for life.

@rouson
Copy link
Collaborator Author

rouson commented Jan 22, 2016

@Tobychev, thanks for these great insights. I'll take this opportunity to put in a plug for Modern Fortran: Style and Usage by Coleman and Specter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants