Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: Matlab mexing with gfortran -- String handling.
From: glen herrmannsfeldt on 26 Apr 2010 07:20
Richard Maine <nospam(a)see.signature> wrote:
(snip)

> The most important part about implicit none for the current purposes is
> *NOT* that it makes you declare what type each variable is. Yes,
> implicit none does that, but that's not the most important part here.
> The important part is that implicit none makes you declare what names
> you are using for variables. That is what helps avoid the typographical
> errors.

In the olden days, compilers would print maps with a list of
all the variables and the address in memory for each.
(Relative address in the object module.) If you saw an unexpected
variable there, you would know to check for typographical errors.

> It is perhaps unfortunate coincidence of terms that a "typing
> error" could refer either to an error relating to data type or a
> typographical error. Those are entirely unrelated problems, except that
> the same words can be used in both contexts and implicit none can relate
> to both. But the errors I am talking about are of the typographical
> variety, which has nothing to do with strict typing.

Also, some typographical errors are easier to make in mixed
case coding. The one/ell error wasn't there in upper case only days.
Most printers designed for computers printed zero and oh different
enough that you could tell them apart from printouts. One of my
favorite was a Xerox printer that printed oh like a script oh with
a little loop at the top. Easy to tell from zero. Some screen
fonts now make it very difficult to tell them apart.

-- glen
From: Uno on 27 Apr 2010 00:42
Richard Maine wrote:
> Uno <merrilljensen(a)q.com> wrote:
>
>> dpb wrote:
>
>>> You seem oblivious to the underlying issues raised re: IMPLICIT NONE
> ...
>> I'm aware that implicit none enforces strict typing,
>
> Actually, no, that is *NOT* the point being made. If that's what you
> think it is about, then you are still missing it. The type aspect is one
> part, but in many ways not the most important part. As Louis said
>
>>>> The whole idea behind 'implicit none' is to force you to declare
>>>> variables so that if you misspell something, the compiler catches it
>>>> for you:
>
> and as I tried to elaborate
>
>>>> I don't think you understood Louis's comment - or my prior one. The
>>>> problem Louis refers to applies to *ANY* implicit typing. Having all
>>>> the types be real lowers the chance of being confused about what
>>>> type something is, but it does *NOTHING* to avoid the problem that
>>>> Louis refers to or many others of its ilk.
>
> but the message doesn't appear to be getting through.
>
> The most important part about implicit none for the current purposes is
> *NOT* that it makes you declare what type each variable is. Yes,
> implicit none does that, but that's not the most important part here.
> The important part is that implicit none makes you declare what names
> you are using for variables. That is what helps avoid the typographical
> errors. It is perhaps unfortunate coincidence of terms that a "typing
> error" could refer either to an error relating to data type or a
> typographical error. Those are entirely unrelated problems, except that
> the same words can be used in both contexts and implicit none can relate
> to both. But the errors I am talking about are of the typographical
> variety, which has nothing to do with strict typing.
>

I am happy to accept any constructive criticism when I ask for a source
check, so I thank you for your reply.

Louis' source was something like this:
$ gfortran -Wall -Wextra r1.f90 -o out
r1.f90:6.7:

r1 = rl + 1.0
1
Error: Symbol 'rl' at (1) has no IMPLICIT type
$ cat r1.f90
implicit none

real r1

r1 = 0.0
r1 = rl + 1.0

endprogram

! gfortran -Wall -Wextra r1.f90 -o out

$

I read Louis very carefully and didn't remember that he was a dude in
c.l.f.!

My contention is that it's strict typing that reveals the mistyping. As
I re-read your reply, I understood of two natures of mistyping:

1) integer :: pi
2) real :: sqfu

I certainly don't want to challenge your opinion on the fortran source
that crosses your desktop.
--
Uno
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: Matlab mexing with gfortran -- String handling.