Function/subroutine declarations

[jacobwilliams]

I always thought that function/subroutine declarations should be done in a similar way as variables. So instead of:

pure elemental function f(x) bind(c,'whatever') result(s)

which to me looks like a haphazard pile of things separated by spaces, you could do this:

function,pure,elemental,bind(c,'whatever'),result(s) :: f(x)

or taking it to the extreme, something like:

function,pure,elemental,bind(c,'whatever'),arguments(x),result(s) :: f

Just a thought.

[certik]

Thanks for submitting the idea, I haven't heard of this one before.

[qolin1]

I agree, would be useful. In addition I would like the PRIVATE and PUBLIC attributes to be available on the declaration.

[FortranFan]

@jacobwilliams, @certik, @qolin1,

I agree there is the risk Fortran language is reaching a point where attributes of procedures can get rather long and unwieldy:

   non_recursive module impure elemental subroutine Fred( .. )
   ! And public/private possibly

The idea of using prefixes to specify procedure attributes may have run its course.

To borrow @jacobwilliams' term, a more Fortrannic approach to deal with this issue might be to introduce a new clause, say ATTRIBUTES, a la RESULT(..) and BIND(..). From what I recall, compiler implementors (and thus the standard committee) appear open to the idea of more clauses to address certain language improvements, especially when it comes to FUNCTIONS. So with a clause, a declaration may look as follows:

   subroutine Fred( .. )
       attributes( public, non_recursive, module, impure, elemental )
   ..

Can you provide your feedback as to whether this alternative involving a subprogram clause is worth a separate issue?

[gronki]

This last proposal looks as if Fortran 77 nightmare was trying to creep back in. In my opinion function attributes are most intuitive before the function name as it is currently.

pt., 27 gru 2019, 02:48 użytkownik FortranFan notifications@github.com napisał:

@jacobwilliams https://github.com/jacobwilliams, @certik https://github.com/certik, @qolin1 https://github.com/qolin1,

I agree there is the risk Fortran language is reaching a point where attributes of procedures can get rather long and unwieldy:

non_recursive module impure elemental subroutine Fred( .. ) ! And public/private possibly

The idea of using prefixes to specify procedure attributes may have run its course.

To borrow @jacobwilliams https://github.com/jacobwilliams' term, a more Fortrannic approach to deal with this issue might be to introduce a new clause, say ATTRIBUTES, a la RESULT(..) and BIND(..). From what I recall, compiler implementors (and thus the standard committee) appear open to the idea of more clauses to address certain language improvements, especially when it comes to FUNCTIONS. So with a clause, a declaration may look as follows:

subroutine Fred( .. ) attributes( public, non_recursive, module, impure, elemental ) ..

Can you provide your feedback as to whether this alternative involving a subprogram clause is worth a separate issue?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/issues/92?email_source=notifications&email_token=AC4NA3MPZDDLQPZ67QKLA4DQ2VNHBA5CNFSM4JOWJVI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHWMEAA#issuecomment-569164288, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3IKXXRHLDLONML4UHTQ2VNHBANCNFSM4JOWJVIQ .

[klausler]

Attributes before the FUNCTION and SUBROUTINE keyword are how things are done today, like it or not. It was a bad design and it restricted at least one syntactic possibility (one can write CHARACTER*7 or CHARACTER(LEN=NAMEDCONSTANT) but not CHARACTER*NAMEDCONSTANT, and that's due at least in part to the ambiguity that would introduce in CHARACTER*IMPUREFUNCTIONFOO()). But that ship has sailed; adding a redundant ATTRIBUTES(...) syntax would not enable any new capability.

[everythingfunctional]

True, the current syntax is far from perfect and leaves much to be desired. But, adding yet another option for syntax is probably not a good solution. There is already a large variation in code style out there, which can make switching between code bases unpleasant. This would simply make that problem even worse.

My vote is that a bad but consistent style is better than a variety of inconsistent styles. Maybe if there was going to be a push to start deprecating old syntaxes and settle on a single style going forward now would be the time to make this change, but I don't really see that as a possibility.