Prev: select specified columns in ch. array
Next: Format with implied do loop
From: Carlie Coats on 26 Jan 2010 09:56

[You may recall the apocryphal story that a period-for-comma typo
combined with implicit types caused the destruction of a NASA rocket
launch -- assignment statement "DO 10 I=1.10" where loop statement
"DO 10 I=1,10" was intended. Some sources indicate the story is
fiction; however, it still is dramatic.]

As I provide debugging-help, I've run into array-assignment
statements of the form

<array> = <scalar>

where the intent was a scalar-assignment statement

<subscripted array element> = <scalar>

Such easy array-assignment syntax *is* seeminglyvery friendly,
but is in a way a form of implicit typing that can lead to
very obscure, hard-to-diagnose bugs.

From my POV, I wish the scalar-to-array-assignment syntax had
been something like (by analogy with RESHAPE()):

<array> = SHAPE( <scalar>, <dimension-list> )

I realize it's too late now;-( but to the extent that similar
opportunities occur in the future, I'd like to encourage some
sort of type-safe syntax.

FWIW -- Carlie Coats



From: robert.corbett on 26 Jan 2010 20:26
On Jan 26, 6:56 am, Carlie Coats <car...(a)jyarborough.com> wrote:

> I realize it's too late now;-( but to the extent that similar
> opportunities occur in the future, I'd like to encourage some
> sort of type-safe syntax.
>
> FWIW -- Carlie Coats

In the early days of Fortran 90 adoption, a common complaint
was about pointer assignment. The statement

P => Q

was often mistakenly written

P = Q

which has a different effect but would not produce an error
or warning because it is also standard conforming. For
whatever reason, complaints about the similarity have ceased
in recent years.

Bob Corbett
From: Carlie Coats on 28 Jan 2010 08:52
Arjen Markus wrote:
[snip...]
> That said, yes, array assignments can be visually misleading.
> I prefer to emphasize them by putting empty lines around
> them, making them stand out a bit. (But I am not sure I do
> that consistently ;)).

And what I'm saying is: that's not good enough. One can not
visually tell the following apart; only (4) and mismatched-shape
versions of (2) are syntax errors, and (3) is a dangerous implicit
type conversion which requires (probably off-screen) declaration
info to realize it's happening:

(1) <scalar> = <scalar>
(2) <array> = <array>
(3) <array> = <scalar>
(4) <scalar> = <array>

My contention is that I wish (3) were also a syntax error,
with functionality replaced by

(3) <array> = SHAPE( <scalar>, <dimension-list> )

so that the accidental, erroneous, *damnably*-hard-to-find
uses of (3) would be caught at compile time.

And that to the extent something like this comes up in the future
(with derived types, etc.?), I'd like the type-converting syntax
to be explicit.

-- Carlie
From: Gordon Sande on 28 Jan 2010 11:07
On 2010-01-28 09:52:03 -0400, Carlie Coats <carlie(a)jyarborough.com> said:

> Arjen Markus wrote:
> [snip...]
>> That said, yes, array assignments can be visually misleading.
>> I prefer to emphasize them by putting empty lines around
>> them, making them stand out a bit. (But I am not sure I do
>> that consistently ;)).
>
> And what I'm saying is: that's not good enough. One can not
> visually tell the following apart; only (4) and mismatched-shape
> versions of (2) are syntax errors, and (3) is a dangerous implicit
> type conversion which requires (probably off-screen) declaration
> info to realize it's happening:
>
> (1) <scalar> = <scalar>
> (2) <array> = <array>
> (3) <array> = <scalar>
> (4) <scalar> = <array>
>
> My contention is that I wish (3) were also a syntax error,
> with functionality replaced by
>
> (3) <array> = SHAPE( <scalar>, <dimension-list> )
>
> so that the accidental, erroneous, *damnably*-hard-to-find
> uses of (3) would be caught at compile time.

Isn't this exactly what FTNCHEK type tools are intended to do?
The problem is that FTNCHECK is for F77 and if it were for F90
you would have to wade through a lot of advisories for OK things.
Or at least until you got all the x(:)'s inplace.

There are a number of "Fortran Lint" products. If you were serious enough
to offer a contract I would guess that some of them might be willing
to help. That requires both the ability of offer a contract and the ability
to subject your code to the ravages of the resulting product. ;-)

> And that to the extent something like this comes up in the future
> (with derived types, etc.?), I'd like the type-converting syntax
> to be explicit.
>
> -- Carlie


From: Ron Shepard on 28 Jan 2010 13:11
In article <7sdj45FmphU1(a)mid.individual.net>,
Carlie Coats <carlie(a)jyarborough.com> wrote:

> (1) <scalar> = <scalar>
> (2) <array> = <array>
> (3) <array> = <scalar>
> (4) <scalar> = <array>
>
> My contention is that I wish (3) were also a syntax error,
> with functionality replaced by
>
> (3) <array> = SHAPE( <scalar>, <dimension-list> )
>
> so that the accidental, erroneous, *damnably*-hard-to-find
> uses of (3) would be caught at compile time.

I'm curious how many times you have made this error in your code and
had trouble finding it. I've been programming with fortran array
syntax for about 17 years now, and I can't remember a single time
that I made this error. Or if I did, it was easy enough to find and
fix and without enough of a hassle for me to remember it.

BTW, when I write these statements, I usually indicate in an inline
comment that an array assignment is happening.

array = array !(:,:)
vector = scalar !(:)

This gives the next programmer (which might be me) a clue, but it is
not enforced or checked for correctness by the compiler.

I think you may be making a tempest in a teapot. In practice this
doesn't seem to be a big deal.

$.02 -Ron Shepard
 |  Next  |  Last
Pages: 1 2 3 4
Prev: select specified columns in ch. array
Next: Format with implied do loop