(j3.2006) Future deprecation of overriding character length, dimension and codimension

Thu Feb 23 11:06:09 EST 2017

On Feb 23, 2017, at 9:58 AM, Bill Long <longb at cray.com<mailto:longb at cray.com>> wrote:

On Feb 22, 2017, at 7:37 PM, Cohen Malcolm <malcolm at nag-j.co.jp<mailto:malcolm at nag-j.co.jp>> wrote:

Ugh.   I would have been happy never being aware of this wart.   Don?t
think I?ve ever seen it in actual code.

A not uncommon style used to be to put all the length specs on the variables
instead of on the type name, e.g.

        CHARACTER A*10,B*4,C*99

This has obvious advantages if you are declaring character variables with
lots of different lengths.

True, but that seems to be quite uncommon.  We already made character*n obsolescent since using the ?*n?  scheme for specifying type parameters is obsolete and undesirable.  I think the same argument should apply to A*10.   But, as Steve pointed out, that was not his proposal.  Rather he wants to prohibit specifying the type parameter or dimensions TWICE in the same statement and having one override the other.

I don't think there is anything wrong with this.  I do not support making
this obsolescent at this time.

Re DIMENSION and CODIMENSION, in my opinion it is the attribute on the
type-spec that is obsolescent, not the one in the entity-decl.  I'd much
rather deprecate those!  We can deprecate the DIMENSION and CODIMENSION
statements while we are at it, they serve no other purpose than to promote
unsafe programming practices.

Specifying a dimension attribute in a declaration does allow you to declare several arrays of the same shape, which can be less error prone if the dimension expressions are complicated.

Agreed.  Also, though perhaps I?m misunderstanding Malcolm?s intent, I think those are also useful when working with an automatic code generator.   It helps to avoid the 132 character limit if attributes are on separate lines and variable names get long:

REAL(kind=REAL32) :: <long-variable-name>
DIMENSION :: <long-variable-name>(:,:,:)
ALLOCATABLE :: <long-variable-name>

Though, I think the proper fix here is to allow lines to be much longer than 132 characters.   (I know, any upper limit will be too small, but O(1000) would solve most preprocessing/code-generation issues I?ve encountered.)

- Tom

However, I do agree that the separate statement forms of most of the attributes are obsolete, unhelpful, and their use results in less readable and maintainable code.  I find separate PARAMETER statements particularly annoying.   The only statement forms that are really justifiable are the ones that can change the attribute for a variable in a contained scope, such as VOLATILE or ASYNCHRONOUS.

Cheers,
Bill

I'm not aware of any other
place in the language where such overriding is allowed.

The way ASYNCHRONOUS and VOLATILE work (unlike every other specification
statement, they override the host associated entity's lack of those
attributes instead of creating a local entity) is much more confusing than
this.

a paper that has to be passed by a majority?

It's WG5, and it's far too late to make technical changes that are not
fixes.  This is not a fix.  And WG5 is supposed to operate by consensus, not
the tyranny of the majority.

WG5 has already made several things obsolescent/deleted this time around.  I
fully expect us to consider making more things obsolescent next time.  Maybe
even delete some things, though that makes little difference to most vendors
other than the wording of the warning message.

Cheers,
--
.............Malcolm Cohen, NAG Oxford/Tokyo.

_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com<mailto:longb at cray.com>
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170223/a0a064d9/attachment-0001.html 