array constructor syntax

[Cornelis]

Since the following code is only accepted by g95 and not by
gfortran-4.2.3 or the intel compiler 10.1, I was wondering if I got
the syntax right.

module array_constructor
implicit none

character(len=14), dimension(5), parameter :: &
var_names = [character(len=14) :: &
'YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']

end module array_constructor

If the syntax is right, I would like to know if there are other
compilers available for x86 under Linux that accept this Fortran 2003
array constructor, since I don't like to be dependent on just one
compiler.

Thanks,

Cornelis

[rusi_pathan]

module array_constructor
implicit none
character(len=14), dimension(5), parameter :: var_names &
& = ['YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']
end module

works on Intel 10.1 and gfortran 4.2.1

[Steven G. Kargl]

In article <d542448a-2ace-49cd...@e39g2000hsf.googlegroups.com>,

You need gfortran 4.4.0. See the wiki.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

[Richard Maine]

rusi_pathan <tabr...@gmail.com> wrote:

> On Sep 1, 3:42 pm, Cornelis <cwdeg...@gmail.com> wrote:
> > Since the following code is only accepted by g95 and not by
> > gfortran-4.2.3 or the intel compiler 10.1, I was wondering if I got

...

> > character(len=14), dimension(5), parameter :: &
> > var_names = [character(len=14) :: &
> > 'YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']

Yes, that looks fine. As you correctly note, it is an f2003 form. I'm
sure the other compilers wil get there eventually, but I can't give you
a timeline.

> character(len=14), dimension(5), parameter :: var_names &
> & = ['YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']
>

> works on Intel 10.1 and gfortran 4.2.1

That, on the other hand, is *NOT* valid in any version of the standard.
Just because some compilers accept it doesn't mean it is valid.

Might I ask whether those compilers at least give a warning for the
nonstandard form when you ask for warnings about standard violation? If
they don't, I'd suggest filing a bug report. While it isn't one of the
particular warnings required by the standard, and thus not strictly a
"bug" in terms of standard compliance, I'd consider it a "bug" in
quality of implementation to fail to give such a warning.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

[Cornelis]

Thanks, Richard, for your elaborate answer.

Both gfortran-4.2 and ifort 10.1 accept rusi's code by default, but
they don't accept it when issued with an option to confirm to the
f2003 standard, -std=f2003 and -e03 respectively.

Steven, thanks: gfortran-4.4 accepts the orginal code and rejects
rusi's code by default.

Cornelis

On Sep 1, 11:27 pm, nos...@see.signature (Richard Maine) wrote:

[alfonsod...@gmail.com]

THIS WAS NOT BUG. gfortran 4.4 *fixed* a blessing we fortunate had in previous versions. This check was left out for a reason, a very good one. People should be given the option to disable this check without disabling other more important checks. As far as I can see this is a totally unnecessary check which only drives people mad if it had any effects. We have large amount of legacy codes and ifort ALWAYS does it correctly, without giving any trouble at all. A little smartness (like having the compiler padding the spaces for humans?) would remove any kind of potential danger.
The downside of going nuts about this little rule is that whenever you insert a longer string you need to redo the whole array. And why on earth would people sit there padding spaces with their eyes strained when they have more important things to do? Besides it makes your code look hideous. What did people do to suffer this atrocity? For these kind of choices where there are some leeway, could you please consider what the user would actually want? And it is obvious, isn't it?

[Richard Maine]

I'm slightly surprised to see a 3.5-year-old thread resurected, but...

<alfonsod...@gmail.com> wrote:

> On Monday, September 1, 2008 2:27:06 PM UTC-7, Richard Maine wrote:
> > rusi_pathan <tabr...@gmail.com> wrote:

> > > character(len=14), dimension(5), parameter :: var_names &
> > > & = ['YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']
> > >
> > > works on Intel 10.1 and gfortran 4.2.1
> >
> > That, on the other hand, is *NOT* valid in any version of the standard.
> > Just because some compilers accept it doesn't mean it is valid.
> >
> > Might I ask whether those compilers at least give a warning for the
> > nonstandard form when you ask for warnings about standard violation? If
> > they don't, I'd suggest filing a bug report. While it isn't one of the
> > particular warnings required by the standard, and thus not strictly a
> > "bug" in terms of standard compliance, I'd consider it a "bug" in
> > quality of implementation to fail to give such a warning.

> THIS WAS NOT BUG. gfortran 4.4 *fixed* a blessing we fortunate had in

> previous versions....[rants a bit]

I'll just say that I disagree. As will anyone who tries to write
portable, standard-conforming code and fails to do so because the
compiler didn't help them catch this error (and it is an error if the
user intended to conform to the standard).

If you want an extension to handle the nonstandard form, I'll mostly
stay out of that argument (other than to note that some of us learned
our lesson about avoiding nonstandard syntax long before array
constructors were around at all; apparently some people were a bit
slower to learn it or maybe still haven't done so). But when the
compiler is asked to diagnose violations of the standard, I maintain
that this is one that it ought to diagnose. To deliberately omit the
diagnosis in the case where the user explicitly asks for standard
conformance checking strikes me as a bug.

> For these kind of choices where there are some leeway, could you please
> consider what the user would actually want? And it is obvious, isn't it?

The simple cases are obvious. Yes. I raised a question about this on
comp.lang.fortran over 20 years ago. Then, at the very first standards
committee meeting I ever went to, slightly after that, I found that my
comp.lang.fortran question had prompted formal committee papers on the
subject. Unfortunately, the general case is not obvious - not at all.
That's why the standard didn't allow it - because any specification
sufficiently general to handle all the cases was going to cause
performance problems that the vendors were very sure that their
customers would all be upset by.

The form added in f2003 specifically addresses this quandry. Yes, it is
slightly verbose, but it is at least clear, easy to implement, and
without the big performance penalty.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:

(snip, someone wrote)

>> THIS WAS NOT BUG. gfortran 4.4 *fixed* a blessing we fortunate had in
>> previous versions....[rants a bit]

> I'll just say that I disagree. As will anyone who tries to write
> portable, standard-conforming code and fails to do so because the
> compiler didn't help them catch this error (and it is an error if the
> user intended to conform to the standard).

> If you want an extension to handle the nonstandard form, I'll mostly
> stay out of that argument (other than to note that some of us learned
> our lesson about avoiding nonstandard syntax long before array
> constructors were around at all; apparently some people were a bit
> slower to learn it or maybe still haven't done so).

Before array constructors, there was the DATA statement for
initializing variables, especially arrays. You could use Hollerith
constants, and they were padded with blanks to the appropriate width.
(Even though the width was implementation dependent.)

It does seem that there might be some cases where it would be
convenient to have the width depend on the data, and that there
are big complications with allowing that. In the case where the
width is given, though, I would hope that it wasn't so hard.

> But when the compiler is asked to diagnose violations of the
> standard, I maintain that this is one that it ought to diagnose.

It seems that one was asking at least to be able to turn off this
one without turning off other warnings, and maybe also that it
wasn't the default to warn about it.

> To deliberately omit the diagnosis in the case where the user
> explicitly asks for standard conformance checking strikes me
> as a bug.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Richard Maine <nos...@see.signature> wrote:
>
> (snip, someone wrote)
> >> THIS WAS NOT BUG. gfortran 4.4 *fixed* a blessing we fortunate had in
> >> previous versions....[rants a bit]
>
> > I'll just say that I disagree. As will anyone who tries to write
> > portable, standard-conforming code and fails to do so because the
> > compiler didn't help them catch this error (and it is an error if the
> > user intended to conform to the standard).
>
> > If you want an extension to handle the nonstandard form, I'll mostly
> > stay out of that argument (other than to note that some of us learned
> > our lesson about avoiding nonstandard syntax long before array
> > constructors were around at all; apparently some people were a bit
> > slower to learn it or maybe still haven't done so).
>
> Before array constructors, there was the DATA statement for
> initializing variables, especially arrays. You could use Hollerith
> constants, and they were padded with blanks to the appropriate width.
> (Even though the width was implementation dependent.)

And none of the complications are relevant in the least to the DATA
statement, largely because the DATA statement isn't actually much like
an array constructor. In particular, each data value in a DATA statement
is processed independently of any others; that alone bypasses the large
majority of the complications.

Note that a character array constructor is also padded to the
appropriate width when used as an initializer or as the right-hand-size
of an assignment statement. That's not where the problem lies. The
problem lies in the consistency of the multiple elements within a single
aray constructor. That issue of consistency between elements does not
come up with DATA statements because of the way that each element is
treated separately.

(And, of course, DATA statements are fine without needing to invoke the
mess that was Hollerith; DATA statements have been allowed for character
type ever since character type was introduced in f77).

> It does seem that there might be some cases where it would be
> convenient to have the width depend on the data, and that there
> are big complications with allowing that. In the case where the
> width is given, though, I would hope that it wasn't so hard.

It isn't hard when the width is given. That's exactly what the f2003
construct does. There is no other case where "the width is given." If
you want to start postulating how the width might be deduced from
context, that's a very different matter and one that has a whole host of
other issues. I can predict suggestion that some situations be
special-cased, to which I'll reply in advance by citing the regular
complaints here about special cases; I am sure that you'd run into
exactly the same kinds of complaints about the allowed form changing
depending on what might seem like trivial unrelated details.

> > But when the compiler is asked to diagnose violations of the
> > standard, I maintain that this is one that it ought to diagnose.
>
> It seems that one was asking at least to be able to turn off this
> one without turning off other warnings, and maybe also that it
> wasn't the default to warn about it.

Perhaps. I can't testify as to what someone else might have meant,
particularly when it is someone who appears to disagree with me about
related things, but note that the poster said "THIS WAS NOT A BUG" (in
caps) in direct response to my

> > Might I ask whether those compilers at least give a warning for the
> > nonstandard form when you ask for warnings about standard violation? If
> > they don't, I'd suggest filing a bug report.

Note my "when you ask for warnings about standard violation." Perhaps
the poster was not actually talking about the case where you ask for
warnings about standard violation, but if he wasn't talking about that
case, then I find the antecedent of his "THIS" to be confusing when it
imediately follows my question about that case. That is, of course,
quite possible. We've all been known to write in ways that make
antecedents unclear (anyway, I sure have).

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:

(snip, I wrote)

>> Before array constructors, there was the DATA statement for
>> initializing variables, especially arrays. You could use Hollerith
>> constants, and they were padded with blanks to the appropriate width.
>> (Even though the width was implementation dependent.)

> And none of the complications are relevant in the least to the DATA
> statement, largely because the DATA statement isn't actually much like
> an array constructor. In particular, each data value in a DATA statement
> is processed independently of any others; that alone bypasses the large
> majority of the complications.

(unsnip, retrieved from the beginning of this thread)

>>> character(len=14), dimension(5), parameter :: &
>>> var_names = [character(len=14) :: &

>>> 'YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']

> Note that a character array constructor is also padded to the
> appropriate width when used as an initializer or as the right-hand-size
> of an assignment statement. That's not where the problem lies. The
> problem lies in the consistency of the multiple elements within a single
> aray constructor. That issue of consistency between elements does not
> come up with DATA statements because of the way that each element is
> treated separately.

Note that in this form the 14 has to be specified in two places.
That is inconvenient, as it requires two changes if the length
changes.

Also, I just noticed that one is a PARAMETER, if that matters.

> (And, of course, DATA statements are fine without needing to
> invoke the mess that was Hollerith; DATA statements have
> been allowed for character type ever since character type
> was introduced in f77).

Yes, I probably didn't need to do that, though that was to show
that they did go back that far, and without any (other) problem.

Most Fortran 66 compilers I used accepted apostrophe'd constants.

>> It does seem that there might be some cases where it would be
>> convenient to have the width depend on the data, and that there
>> are big complications with allowing that. In the case where the
>> width is given, though, I would hope that it wasn't so hard.

> It isn't hard when the width is given. That's exactly what the f2003
> construct does. There is no other case where "the width is given." If
> you want to start postulating how the width might be deduced from
> context, that's a very different matter and one that has a whole host of
> other issues. I can predict suggestion that some situations be
> special-cased, to which I'll reply in advance by citing the regular
> complaints here about special cases;

I might agree that I don't like special cases, though initializing
an array with constants is a lot more common than initializing
with complicated expressions.

> I am sure that you'd run into
> exactly the same kinds of complaints about the allowed form changing
> depending on what might seem like trivial unrelated details.

If you can do it like:

character(len=14), dimension(5), parameter :: &
var_names = [character(len=len(var_names)) :: &

'YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']

That removes the need to specify the length twice. I think that
works, but I am not sure that it does.

-- glen

[Ian Harvey]

On 2012-04-05 4:42 PM, glen herrmannsfeldt wrote:
> Richard Maine<nos...@see.signature> wrote:
>

...

>
> (unsnip, retrieved from the beginning of this thread)
>
>>>> character(len=14), dimension(5), parameter ::&
>>>> var_names = [character(len=14) ::&
>>>> 'YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']
>

...

>
> Note that in this form the 14 has to be specified in two places.
> That is inconvenient, as it requires two changes if the length
> changes.
>
> Also, I just noticed that one is a PARAMETER, if that matters.

In this case you can (and should from the POV of code clarity) replace
the first 14 (the one in the type-spec at the start of the statement)
with *.

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

[quoting someone else]

> >>> character(len=14), dimension(5), parameter :: &
> >>> var_names = [character(len=14) :: &
> >>> 'YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']
>

> Note that in this form the 14 has to be specified in two places.
> That is inconvenient, as it requires two changes if the length
> changes.

As Ian noted, no it doesn't, at least in the case of a parameter, and
you did subsequently talk about special-casing parameters.

Besides which, numbers like that should often be specified as parameters
themselves, particularly if they apear in more than one place. In that
case, no changing it does not require making a change in more than one
place. I don't think that failure to follow good practice in using
things introduced in Fortran 77 (parameters) is a very good rationale
for introducing special cases into the language. I do agree it is
verbose (I suspect I mentioned that before).

> I might agree that I don't like special cases, though initializing
> an array with constants is a lot more common than initializing
> with complicated expressions.

I smell a camel's nose (and from my limitted exposure at zoos and the
like, I'd say camels tend to smell pretty bad). As soon as you do that,
I am *SURE* someone else will complain that a slight variation also
ought to work. Not a complicated expression, but a simple one, such as

['infile','oufile','errorfile'] // '.txt'

or some such thing. Then perhaps something to handle the resulting
embedded blanks, etc., etc.. It is really, really hard to get people to
agree on the exact boundaries of special cases. And then you end up with
a messy rule that people *WILL* complain about.

I predict that you'd end up with complaints if it worked for parameters,
but the same form didn't work for initializing a variable (just like
I've heard complaints about the * length only working for parameters.)
And then people will want the same thing to work in an assignment
statement as well as in an initializer. Then people will bitch that it
doesn't work for an allocatable-length character array. It goes on
pretty much infinitely.

The question is not so much what you, or any other one person, might
think is good to special case, but rather what you could get broad
agreement on. I think you'll find that the easiest set to get agreement
on special-casing here is... the set that was agreed on at least enough
to pass, namely the null set.

--
Richard Maine

email: last name at domain . net

domain: summer-triangle