exact rules for double colon (::)

[Anton Shterenlikht]

Just wanted to confirm here I understand
the standard exactly. Looking at f2008
(http://j3-fortran.org/doc/standing/links/007.pdf)
in 5.2 Type declaration statements,
rule R501 and constraint C505,
my reading is:

double colon must appear if
- there is at least one attribute
or
- if initialisation appears

However, it is not an error to include
double colon even where it is not required.

Is that correct?

Thanks

Anton

[Richard Maine]

Sounds right. I make it a habit to always use the double colon. That
way, I don't need to worry about whether or not it might be needed. I
also then don't have to remember to add it in if I change something else
in a way that makes it needed. There's much to be said for consistency.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Dick Hendrickson]

That is correct. The double colon is optional if you aren't doing
anything fancy. I think most people always use it (except maybe
Terrence) as a matter of good style.

The reason for requiring it in those two cases is to 1) separate the
list of attribute names from the list of entity names and 2)
disambiguate type statements from assignment statements (in fixed form).

Dick Hendrickson

[Dick Hendrickson]

Yeah. The one problem with consistency is the ONLY clause in a USE.
That requires a single colon. I think that's been fixed in F2012 or so
and allows an optional second colon.

Dick Hendrickson

[glen herrmannsfeldt]

Dick Hendrickson <dick.hen...@att.net> wrote:
> On 8/1/13 9:56 AM, Anton Shterenlikht wrote:

(snip)

>> my reading is:

>> double colon must appear if
>> - there is at least one attribute
>> or
>> - if initialisation appears

>> However, it is not an error to include
>> double colon even where it is not required.

(snip)

> That is correct. The double colon is optional if you aren't doing
> anything fancy. I think most people always use it (except maybe
> Terrence) as a matter of good style.

> The reason for requiring it in those two cases is to 1) separate
> the list of attribute names from the list of entity names and 2)
> disambiguate type statements from assignment statements
> (in fixed form).

In a recent discussion on complex multiply, I tried:

complex z=sqrt((-1,0))
print *,z
print *,cmplx(z,kind(1.d0))
end

Forgetting the need for such colons in this case. The program
compiles and gives different results than with the ::.

-- glen

[Steven G. Kargl]

I suppose someone needs to ask for the details. What broken
compiler?

--
steve

[Richard Maine]

I would expect that to behave as Glen describes with most compilers,
provided that

1. It is compiled as fixed source form. Not that I tend to use fixed
source form unless I am working with some code given to me that way.
This illustrates one of tge reasins that I consider using fixed source
form to be undesirable.

2. It fails to use implicit none. Indeed there is none evident in the
code as shown. Another undesirable practice. Admitedly I might well omit
it if I were really doing a 4-line program like that, but then if I were
doing a quickie 4-line program to test something, I wouldn't be using
fixed source form.

3. The compiler does not warn about even simple cases of referencing
undefined variables.

and

4. Glen's post has a typo that his actual code did not. Namely, I assume
that the argument to sqrt was actually -1.0 instead of 2 integer
arguments -1 and 0.

[glen herrmannsfeldt]

Steven G. Kargl <s...@removetroutmask.apl.washington.edu> wrote:

(snip, I wrote)

>> In a recent discussion on complex multiply, I tried:

>> complex z=sqrt((-1,0))
>> print *,z
>> print *,cmplx(z,kind(1.d0))
>> end

>> Forgetting the need for such colons in this case. The program
>> compiles and gives different results than with the ::.

> I suppose someone needs to ask for the details. What broken
> compiler?

Currently gfortran 4.4.5.

(By the way, it is fixed form. It won't compile in free form.)

As to the OP, this is the case where the :: is required, and the
comiler won't detect it. It comes from mixing old-style declarations
with new-style initialization.

-- glen

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> Steven G. Kargl <s...@REMOVEtroutmask.apl.washington.edu> wrote:

(snip, I wrote)

>> > In a recent discussion on complex multiply, I tried:

>> > complex z=sqrt((-1,0))
>> > print *,z
>> > print *,cmplx(z,kind(1.d0))
>> > end

(snip)

>> I suppose someone needs to ask for the details. What broken
>> compiler?

> I would expect that to behave as Glen describes with most compilers,
> provided that

> 1. It is compiled as fixed source form.

Yes.

(snip)

> 2. It fails to use implicit none. Indeed there is none evident in the
> code as shown. Another undesirable practice. Admitedly I might well omit
> it if I were really doing a 4-line program like that, but then if I were
> doing a quickie 4-line program to test something, I wouldn't be using
> fixed source form.

I do tend to use it for four line programs. Maybe I just go too
used to it in years past. Also, I like to indent programs in posts,
which automatically happens.

> 3. The compiler does not warn about even simple cases of referencing
> undefined variables.

As noted, this is gfortran. I used no command-line options.

> 4. Glen's post has a typo that his actual code did not. Namely, I
> assume that the argument to sqrt was actually -1.0 instead
> of 2 integer arguments -1 and 0.

It is as written, copy and paste exactly. I haven't looked up the
requirements for complex constants lately, though, to be sure.
In any case, gfortran accepts the constant as written, and separate
from the bug in the program.

OK, it looks to me like it is legal in F08, but not in F66.
I don't know when the change was made.

-- glen

[Steven G. Kargl]

On Thu, 01 Aug 2013 13:28:21 -0700, Richard Maine wrote:

> Steven G. Kargl <s...@REMOVEtroutmask.apl.washington.edu> wrote:
>
>> On Thu, 01 Aug 2013 19:26:36 +0000, glen herrmannsfeldt wrote:
>
>> > In a recent discussion on complex multiply, I tried:
>> >
>> > complex z=sqrt((-1,0))
>> > print *,z
>> > print *,cmplx(z,kind(1.d0))
>> > end
>> >
>> > Forgetting the need for such colons in this case. The program
>> > compiles and gives different results than with the ::.
>>
>> I suppose someone needs to ask for the details. What broken
>> compiler?
>
> I would expect that to behave as Glen describes with most compilers,
> provided that
>
> 1. It is compiled as fixed source form. Not that I tend to use fixed
> source form unless I am working with some code given to me that way.
> This illustrates one of tge reasins that I consider using fixed source
> form to be undesirable.

Thanks for using your Glen telepathy powers. This is, indeed, the
details that I was missing. I very rarely write or even look at fixed
form code.

> 2. It fails to use implicit none. Indeed there is none evident in the
> code as shown. Another undesirable practice. Admitedly I might well omit
> it if I were really doing a 4-line program like that, but then if I were
> doing a quickie 4-line program to test something, I wouldn't be using
> fixed source form.

When doing quick and dirty short programs, my fingers invariably
type the 2 lines:

program foo
implicit none

Given my poor typing skills, these lines have saved my countless
debugging sessions.

--
steve

[Richard Maine]

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

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

> > 4. Glen's post has a typo that his actual code did not. Namely, I
> > assume that the argument to sqrt was actually -1.0 instead
> > of 2 integer arguments -1 and 0.
>
> It is as written, copy and paste exactly. I haven't looked up the
> requirements for complex constants lately, though, to be sure.
> In any case, gfortran accepts the constant as written, and separate
> from the bug in the program.
>
> OK, it looks to me like it is legal in F08, but not in F66.
> I don't know when the change was made.

Ah. I'm just not used to writing complex literals, so I missed that (and
the extra parens that meant it could not be 2 arguments).

[Dick Hendrickson]

F90.

Dick Hendrickson

>
> -- glen

[glen herrmannsfeldt]

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

(snip, I wrote)

>> It is as written, copy and paste exactly. I haven't looked up the
>> requirements for complex constants lately, though, to be sure.
>> In any case, gfortran accepts the constant as written, and separate
>> from the bug in the program.

>> OK, it looks to me like it is legal in F08, but not in F66.
>> I don't know when the change was made.

> Ah. I'm just not used to writing complex literals, so I missed
> that (and the extra parens that meant it could not be 2
> arguments).

Yes, I don't write complex literals all that often.

Fortran 2008 seems to allow signed-int-literal-constant,
signed-real-literal-constant or named-constant for the
two parts of a complex constant.

-- glen

[robin....@gmail.com]

On Friday, August 2, 2013 5:26:36 AM UTC+10, glen herrmannsfeldt wrote:

It shouldn't have compiled at all, with the error
in the 3rd statement.

[robert....@oracle.com]

On Thursday, August 1, 2013 6:24:46 PM UTC-7, robin....@gmail.com wrote:

> > In a recent discussion on complex multiply, I tried:
> >
> > complex z=sqrt((-1,0))
> > print *,z
> > print *,cmplx(z,kind(1.d0))
> > end
> >
> > Forgetting the need for such colons in this case. The program
> > compiles and gives different results than with the ::.
>
> It shouldn't have compiled at all, with the error
> in the 3rd statement.

The third statement is standard conforming. Because of the missing double colon in the first line, the type of the variable z in the third line is REAL. The intrinsic function cmplx is allowed to have mixed INTEGER and REAL expressions as arguments.

When the colons are added, the third statement is not standard conforming, but the error is not a syntax error or a constraint violation. A standard conforming processor is allowed to accept forms of intrinsic functions in addition to those listed in the Fortran standard. A program that uses those forms is not standard conforming, but the standard does not yet require a standard conforming processor to diagnose such usage. A proposal to add such a requirement to the next standard was considered at the last SC22/WG5 meeting, but I do not know if it was accepted.

Bob Corbett

[robin....@gmail.com]

On Friday, August 2, 2013 4:37:51 PM UTC+10, robert....@oracle.com wrote:
> On Thursday, August 1, 2013 6:24:46 PM UTC-7, robin....@gmail.com wrote:
>
>
>
> > > In a recent discussion on complex multiply, I tried:
>
> > >
>
> > > complex z=sqrt((-1,0))
>
> > > print *,z
>
> > > print *,cmplx(z,kind(1.d0))
>
> > > end
>
> > >
>
> > > Forgetting the need for such colons in this case. The program
>
> > > compiles and gives different results than with the ::.
>
> >
>
> > It shouldn't have compiled at all, with the error
>
> > in the 3rd statement.
>
>
>
> The third statement is standard conforming.

No it's not. In the case cited, Glen states that the code gives different results with the
colons present.

With the colons present, z is COMPLEX.
The code CANNOT compile.

> Because of the missing double colon in the first line, the type of the variable z in the third line is REAL.

You might _think_ so, but that is not so.
with the colons missing, compilation fails at line 1
(two adjacent variables).

(Even in fixed source form, the error still is diagnosed, and the program is in error.)

> The intrinsic function cmplx is allowed to have mixed INTEGER and REAL expressions as arguments.

That is so, but that isn't the case that Glen cites.

> When the colons are added, the third statement is not standard conforming, but the error is not a syntax error or a constraint violation.

Tell that to my compiler, which diagnoses it as
a fatal error.

> A standard conforming processor is allowed to accept forms of intrinsic functions in addition to those listed in the Fortran standard. A program that uses those forms is not standard conforming, but the standard does not yet require a standard conforming processor to diagnose such usage.

A compiler that didn't diagnose that error
is broken.

[robert....@oracle.com]

On Friday, August 2, 2013 12:37:18 AM UTC-7, robin....@gmail.com wrote:
> On Friday, August 2, 2013 4:37:51 PM UTC+10, robert....@oracle.com wrote:
>
> > On Thursday, August 1, 2013 6:24:46 PM UTC-7, robin....@gmail.com wrote:
> >
> > > > In a recent discussion on complex multiply, I tried:
>
> > > > complex z=sqrt((-1,0))
> > > > print *,z
> > > > print *,cmplx(z,kind(1.d0))
> > > > end
> > > >
> > > > Forgetting the need for such colons in this case. The program
> > > > compiles and gives different results than with the ::.
>
> > > It shouldn't have compiled at all, with the error
> > > in the 3rd statement.
>
> > The third statement is standard conforming.
>
> No it's not.

Yes, it is. Glen said that he is using fixed form. In fixed form, the first line is an assignment statement and type of the variable z in the third line is REAL. The only aspect of the program that is not standard conformant is that it references an undefined variable.

In the case cited, Glen states that the code gives different results with the
> colons present.

He also said it compiles.

> With the colons present, z is COMPLEX.
> The code CANNOT compile.

Yet it did.

The Fortran standard is a permissive standard. Except in the cases cited in the standard, a conforming processor is not required to diagnose a usage in a program that is not standard conforming. The standard explicitly allows a conforming processor to provide intrinsic functions not specified in the standard.

>
> > Because of the missing double colon in the first line, the type of the variable z in the third line is REAL.

> You might _think_ so, but that is not so.

The Fortran standard does not agree with you.

> with the colons missing, compilation fails at line 1
> (two adjacent variables).

The first statement is a conforming assignment statement in fixed form.

>
> (Even in fixed source form, the error still is diagnosed, and the program is in error.)

There is no error if the program is compiled for fixed source form.

>
>
> > The intrinsic function cmplx is allowed to have mixed INTEGER and REAL expressions as arguments.
>
>
>
> That is so, but that isn't the case that Glen cites.
>
>
>
> > When the colons are added, the third statement is not standard conforming, but the error is not a syntax error or a constraint violation.
>
> Tell that to my compiler, which diagnoses it as
> a fatal error.

The the Conformance clause of Fortran standard gives specific rules regarding which errors must be diagnosed. A conforming processor is required to diagnose those errors. The use of cmplx in the program above is not among those cases. A confoming processor may diagnose errors beyond those it is required to diagnose.

>
> > A standard conforming processor is allowed to accept forms of intrinsic functions in addition to those listed in the Fortran standard. A program that uses those forms is not standard conforming, but the standard does not yet require a standard conforming processor to diagnose such usage.
>
> A compiler that didn't diagnose that error
> is broken.

The Fortran standard does not require a conforming processor to diagnose that error.

>
> > A proposal to add such a requirement to the next standard was considered at the last SC22/WG5 meeting, but I do not know if it was accepted.

Bob Corbett

[Terence]

Dick Hendrickson assumes:-

>That is correct. The double colon is optional if you aren't doing
>anything fancy. I think most people always use it (except maybe
>Terrence) as a matter of good style.

This particularly-named Terence always uses double colons for F90/95
compiled code and has never used a later compiler. I hope the other guy
understands this point.

Following a standard is not necesarily enogh to ensure writing good code.
:o)>

[robin....@gmail.com]

On Saturday, August 3, 2013 6:19:14 AM UTC+10, robert....@oracle.com wrote:
> On Friday, August 2, 2013 12:37:18 AM UTC-7, robin....@gmail.com wrote:
>
> > On Friday, August 2, 2013 4:37:51 PM UTC+10, robert....@oracle.com wrote:
>
> >
>
> > > On Thursday, August 1, 2013 6:24:46 PM UTC-7, robin....@gmail.com wrote:
>
> > >
>
> > > > > In a recent discussion on complex multiply, I tried:
>
> >
>
> > > > > complex z=sqrt((-1,0))
>
> > > > > print *,z
>
> > > > > print *,cmplx(z,kind(1.d0))
>
> > > > > end
>
> > > > >
>
> > > > > Forgetting the need for such colons in this case. The program
> > > > > compiles and gives different results than with the ::.
>
> > > > It shouldn't have compiled at all, with the error
> > > > in the 3rd statement.

> > > The third statement is standard conforming.

> > No it's not.

> Yes, it is. Glen said that he is using fixed form. In fixed form, the first line is an assignment statement and type of the variable z in the third line is REAL. The only aspect of the program that is not standard conformant is that it references an undefined variable.

In fixed source form, with the colons present,
the program shouldn't have compiled at all, because the third statement is in error.

In fixed source form, there are two instances of
referencing an undefined variable.

> > In the case cited, Glen states that the code gives different results with the
> > colons present.

> He also said it compiles.

He may be mistaken.

> > With the colons present, z is COMPLEX.
> > The code CANNOT compile.

> Yet it did.

If it did, the compiler is broken.
For a complex first argument, the second argument
MUST be omitted.

> The Fortran standard is a permissive standard. Except in the cases cited in the standard, a conforming processor is not required to diagnose a usage in a program that is not standard conforming. The standard explicitly allows a conforming processor to provide intrinsic functions not specified in the standard.

Use your common sense.
For something that isn't standard-conforming,
the compiler needs to issue an error message.

> > > Because of the missing double colon in the first line, the type of the variable z in the third line is REAL.

> > You might _think_ so, but that is not so.

> The Fortran standard does not agree with you.

> > with the colons missing, compilation fails at line 1
> > (two adjacent variables).

> The first statement is a conforming assignment statement in fixed form.
>
> > (Even in fixed source form, the error still is diagnosed, and the program is in error.)

> There is no error if the program is compiled for fixed source form.

There is at least one error. See previous line.

> > > The intrinsic function cmplx is allowed to have mixed INTEGER and REAL expressions as arguments.
>
> > That is so, but that isn't the case that Glen cites.
>
> > > When the colons are added, the third statement is not standard conforming, but the error is not a syntax error or a constraint violation.

It's called a semantic error -- an error that
every compiler needs to diagnose.

> > Tell that to my compiler, which diagnoses it as
> > a fatal error.
>
> The the Conformance clause of Fortran standard gives specific rules regarding which errors must be diagnosed. A conforming processor is required to diagnose those errors. The use of cmplx in the program above is not among those cases. A confoming processor may diagnose errors beyond those it is required to diagnose.
>
> > > A standard conforming processor is allowed to accept forms of intrinsic functions in addition to those listed in the Fortran standard. A program that uses those forms is not standard conforming, but the standard does not yet require a standard conforming processor to diagnose such usage.

That's foolish reasoning.
Under that guise, it's quite OK for the compiled
code to add 2 + 2 and get 5.

> > A compiler that didn't diagnose that error
> > is broken.
>
> The Fortran standard does not require a conforming processor to diagnose that error.

You rely too much on the standard.
For what is unequivically a semantic error,
an error message must be delivered.
If it is not, the compiler is broken.

[Richard Maine]

<robin....@gmail.com> wrote:
[stuff]

> On Saturday, August 3, 2013 6:19:14 AM UTC+10, robert....@oracle.com wrote:

[other stuff]

I'm betting that Robert, being a pretty smart guy, ought to be able to
figure out why I try to avoid arguing with Robin. I prefer things more
likely to have productive results (I say as I head back to replaying
Oblivion :-)).

[Terence]

Rule one in C-L-F:
Robin is usually correct.
I avoid saying 'Always' since my expertice is in statitics and 'the
universe' of possibilities is near infinite..

[Dan Nagle]

Hi,

On 2013-08-06 15:57:10 +0000, Richard Maine said:

> <robin....@gmail.com> wrote:
> [stuff]
>> On Saturday, August 3, 2013 6:19:14 AM UTC+10, robert....@oracle.com wrote:
> [other stuff]
>
> I'm betting that Robert, being a pretty smart guy, ought to be able to
> figure out why I try to avoid arguing with Robin. I prefer things more
> likely to have productive results (I say as I head back to replaying
> Oblivion :-)).

Bob's dissertation at Berkeley was the basis for many compiler's error
processing for many years.

Having met Bob and worked with him on J3, I can say that he's one of the nicest
people I've ever met.

--
Cheers!

Dan Nagle

[John Harper]

robin....@gmail.com wrote:

> For something that isn't standard-conforming,
> the compiler needs to issue an error message.

Do you have a compiler that issues one for the integer overflow in this
program? None of my four compilers will.

program trybadint
implicit none
integer i
do i = 1,range(i)+1
print *, 10**i
end do
end program trybadint

--
John Harper

[William Clodius]

Anyone who believes that about Robin has some serious problems with
their understanding of Fortran, and evaluating arguments in general. A
good rule to follow is that someone that can cite chapter and verse are
more likely to be correct than someone who argues by assertion.

[Richard Maine]

I find it sadly amusing when this includes two assertions in the same
post that pretty directly contradict each other. Namely that the
standard must be followed, as asserted by

>>> For something that isn't standard-conforming,
>>> the compiler needs to issue an error message.

but when Bob quoted chapter and verse on the standard's requirements for
error mesages, the reply was that people shouln't pay too much attention
to the standard as asserted by

>>> You rely too much on the standard.

I'm fairly used to such contradictory assertions, but they are usually
at least in separate posts.

For amusement, I used cut&paste to exactly copy the code that Glen said
compiled, to which Robin replied

>>> He may be mistaken.

The code compiled and ran without error on all 3 compilers I tried. Two
of them gave no messages at all with default compiler options (I didn't
bother trying non-default options). The third compiler (NAG) did give 2
warnings with default options, but neither was about the error in
question (the use of an undefined variable). It warned about the use of
fixed source form (obsolescent) and about a variable being set, but
never used. But I guess, I also "may be mistaken."

There are, of course, innumerable ways in which a code can be
nonconformant with the standard, yet be literally impossible for a
compiler to diagnose. That's not counting the cases that are possible,
but impractical.

If one ignores what the standard says about error reporting
requirements, one is likely to be pretty puzzled by the numerous
apparently redundant and superfluous requirements in the (very) general
form

if condition then requirement
(unconditionally) requirement

Seems sort of pointless to say that the requirement applies in one
condition, and also, by the way, all the time. :-)
The only reason it isn't redundant is the the conditional case is a
constraint, which means that compilers have to be able to diagnose it in
that case.

Even as it is, I still find that a little confusing because the
constraint tends to come prior to the more general one. So if I'm
reading along, I see the constraint first and it makes me imediately
wonder about the cases that don't meet the condition. I think it would
read better if the general requirement were stated first and the case
where diagnostic ability was required came afterwards and made it clear
that it was a subset of the general rule. But that would be a pretty
large amount of editorial work.

I was going to say that the shortest example I could think of for an
error impossible for a compiler to diagnose was along the lines of

read(*,*) x,y
write (*,*) x**y
end

where the compiler cannot know whether x is negative. The runtimes might
produce a diagnostic, but no compiler can do so.

But it then occured to me that an even simpler case is

read (*,*) x
write (*,*) x
end

where the compiler cannot know whether the input data is in a valid
form. Interestingly (to me), that's a case that has bitten me in the
past because different compiler runtimes handle invalid input
differently (as the standard allows them to do). Some consider things
like 1.2q3 to be equivalent to 1.2e3, at least one compiler "fixed" the
q by interpreting the field as 1.203, and some reject the whole thing as
an error.

[glen herrmannsfeldt]

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

(snip)

> There are, of course, innumerable ways in which a code can be
> nonconformant with the standard, yet be literally impossible for a
> compiler to diagnose. That's not counting the cases that are possible,
> but impractical.

(snip)

> But it then occured to me that an even simpler case is

> read (*,*) x
> write (*,*) x
> end

> where the compiler cannot know whether the input data is in a valid
> form. Interestingly (to me), that's a case that has bitten me in the
> past because different compiler runtimes handle invalid input
> differently (as the standard allows them to do). Some consider
> things like 1.2q3 to be equivalent to 1.2e3, at least one
> compiler "fixed" the q by interpreting the field as 1.203,
> and some reject the whole thing as an error.

IBM Fortran H Extended, unlike G and H, supports both REAL*16
and list-directed I/O. For REAL*16 there is a Q format descriptor
which outputs values with Q exponents, and Q is allowed in exponents
for input.

VAX also has REAL*16, but I don't remember if it has the Q format
descriptor. Seems like it would to be compatible with IBM.

-- glen

[Ian Chivers]

Nag gives a run time error with -C=all

c:\document\fortran\latex_fortran_book\new_examples>nagfor
overflow01.f90 -C=all
NAG Fortran Compiler Release 5.3.1(924)
[NAG Fortran Compiler normal termination]

c:\document\fortran\latex_fortran_book\new_examples>a.exe
10
100
1000
10000
100000
1000000
10000000
100000000
1000000000
Runtime Error: overflow01.f90, line 5: Integer overflow for
exponentiation 10**1
Program terminated by fatal error

c:\document\fortran\latex_fortran_book\new_examples>

This was added in a recent release.

From a training point of view Jane Sleightholme
and I recommend Nag very highly.

We've been teaching with it since 1995 or there abouts.

Cheers

Ian

[Steve Lionel]

On 8/7/2013 12:37 AM, glen herrmannsfeldt wrote:
> IBM Fortran H Extended, unlike G and H, supports both REAL*16
> and list-directed I/O. For REAL*16 there is a Q format descriptor
> which outputs values with Q exponents, and Q is allowed in exponents
> for input.
>
> VAX also has REAL*16, but I don't remember if it has the Q format
> descriptor. Seems like it would to be compatible with IBM.

VAX Fortran (and DEC/Compaq/Intel Fortran successors) support Q as an
exponent letter in a real constant literal, but don't have a format edit
descriptor that will insert a Q as an exponent letter in output. (They
will all accept a Q on input, though.) These do all have a Q edit
descriptor, albeit one with an entirely different meaning than discussed
here.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.

[Walt Brainerd]

On 8/6/2013 9:36 AM, robin....@gmail.com wrote:
>
> You rely too much on the standard.
> For what is unequivically a semantic error,
> an error message must be delivered.

.
I will comment on just this one thing.
Semantics deals with meaning (at least
according to the Greeks and Wiki).

It is syntax errors that a compiler must
diagnose according to the standard (i.e.,
constraints).

[Tobias Burnus]

Am 07.08.2013 21:16, Steve Lionel wrote:
> On 8/7/2013 12:37 AM, glen herrmannsfeldt wrote:
>> IBM Fortran H Extended, unlike G and H, supports both REAL*16
>> and list-directed I/O. For REAL*16 there is a Q format descriptor
>> which outputs values with Q exponents, and Q is allowed in exponents
>> for input.
>> VAX also has REAL*16, but I don't remember if it has the Q format
>> descriptor. Seems like it would to be compatible with IBM.
>
> VAX Fortran (and DEC/Compaq/Intel Fortran successors) support Q as an
> exponent letter in a real constant literal, but don't have a format edit
> descriptor that will insert a Q as an exponent letter in output. (They
> will all accept a Q on input, though.) These do all have a Q edit
> descriptor, albeit one with an entirely different meaning than discussed
> here.

That's similar to gfortran - which supports it since GCC 4.8 for I/O
input and in the source code for exponents in literals to denote
quad-precision (except for -std=f95/f2003/f2008/f2008ts). Like
VAX/DEC/Compaq/Intel's compiler, gfortran has no edit descriptor to
produce a 'q' on output.

Seemingly, there is still quite some code around, which uses it in files
to be read by Fortran - and in the source code. As one should be
friendly to older source code, it has been added to gfortran just a year
ago.

Tobias

[robin....@gmail.com]

On Wednesday, August 7, 2013 2:23:52 PM UTC+10, Richard Maine wrote:

> I find it sadly amusing when this includes two assertions in the same
> post that pretty directly contradict each other. Namely that the
> standard must be followed, as asserted by
>
> >>> For something that isn't standard-conforming,
> >>> the compiler needs to issue an error message.
>
> but when Bob quoted chapter and verse on the standard's requirements for
> error mesages, the reply was that people shouln't pay too much attention
> to the standard as asserted by

No, that's not what I said, and you know it.
Unequivocally, the remark [next line] was directly about what HE argued.

> >>> You rely too much on the standard.

> I'm fairly used to such contradictory assertions, but they are usually
> at least in separate posts.

It's not contradictory.
He relied overly on quoting the standard instead of using his common sense.

> For amusement, I used cut&paste to exactly copy the code that Glen said
> compiled, to which Robin replied

> >>> He may be mistaken.

He may have suppressed warnings, etc, by default, and not realized
that the compilers could have given one or more diagnostics.

> The code compiled and ran without error on all 3 compilers I tried. Two

So what?
Your compilers are broken.

> Two of them gave no messages at all with default compiler options (I didn't
> bother trying non-default options).

Doesn't give you a strong argument, does it!

> The third compiler (NAG) did give 2
> warnings with default options, but neither was about the error in
> question (the use of an undefined variable).

Your compiler is broken, or you should have compiled with the relevant
options.

> It warned about the use of
> fixed source form (obsolescent) and about a variable being set, but
> never used. But I guess, I also "may be mistaken."

Funny, isn't it!
Why not invest in a decent compiler?
Mine gives an explicit message about an undefined variable.
And that's with default options.

> There are, of course, innumerable ways in which a code can be
> nonconformant with the standard, yet be literally impossible for a
> compiler to diagnose.

That's entirely irrelevant.
There are many errors that can be diagnosed easily.

> That's not counting the cases that are possible,
> but impractical.

Certainly not impractical.

> If one ignores what the standard says about error reporting
> requirements, one is likely to be pretty puzzled by the numerous
> apparently redundant and superfluous requirements in the (very) general
> form
>
> if condition then requirement
> (unconditionally) requirement
>
> Seems sort of pointless to say that the requirement applies in one
> condition, and also, by the way, all the time. :-)
> The only reason it isn't redundant is the the conditional case is a
> constraint, which means that compilers have to be able to diagnose it in
> that case.
>
> Even as it is, I still find that a little confusing because the
> constraint tends to come prior to the more general one. So if I'm
> reading along, I see the constraint first and it makes me imediately
> wonder about the cases that don't meet the condition. I think it would
> read better if the general requirement were stated first and the case
> where diagnostic ability was required came afterwards and made it clear
> that it was a subset of the general rule. But that would be a pretty
> large amount of editorial work.

So you are saying that the standards people can't be bothered
putting in a statement that compilers are required to diagnose
semantic errors, etc.

[Dan Nagle]

Hi,

On 2013-08-09 02:33:38 +0000, robin....@gmail.com said:

> So you are saying that the standards people can't be bothered
> putting in a statement that compilers are required to diagnose
> semantic errors, etc.

Please see the standard, Subclause 1.5 at [23:5-43].

--
Cheers!

Dan Nagle

[robin....@gmail.com]

On Wednesday, August 7, 2013 2:23:52 PM UTC+10, Richard Maine wrote:

> There are, of course, innumerable ways in which a code can be
> nonconformant with the standard, yet be literally impossible for a
> compiler to diagnose. That's not counting the cases that are possible,
> but impractical.

Errors can be diagnosed at compile time, and/or by the compiler's run-time.

> I was going to say that the shortest example I could think of for an
> error impossible for a compiler to diagnose was along the lines of

> read(*,*) x,y
> write (*,*) x**y
> end

> where the compiler cannot know whether x is negative. The runtimes might
> produce a diagnostic, but no compiler can do so.

The compiler's run-time can, in that case.

[Terence]

Apart from feeling that Robin is correct as the exchange occured, due to
incomplete available diagnostics being applied/allowed on the various
testings of the code, as he suggested might be happening, Robin's final
observation on the critism is the whole point:-

>So you are saying that the standards people can't be bothered
>putting in a statement that compilers are required to diagnose
>semantic errors, etc.

Please don't tell me that's true!
Semantic errors must be noted by the compiler.
That should be in the standards for compilers.
I wouid be surprised if this were absent from standards committee
agreements.
The major point of Fortran is that there are no special reserved words, so
semantics are everything.

[Ian Harvey]

On 2013-08-09 4:48 PM, Terence wrote:
> Apart from feeling that Robin is correct as the exchange occured, due to
> incomplete available diagnostics being applied/allowed on the various
> testings of the code, as he suggested might be happening, Robin's final
> observation on the critism is the whole point:-
>
>> So you are saying that the standards people can't be bothered
>> putting in a statement that compilers are required to diagnose
>> semantic errors, etc.
>
> Please don't tell me that's true!
> Semantic errors must be noted by the compiler.

Lets hit google. "Semantic error - an error in logic or arithmetic that
must be detected at run time."

An error in meaning. That is, the program means something, but that
something is not what the programmer intended.

How can a *compiler*, in the general case, detect an error that occurs
at *run time*? How can the compiler, in the general case, know what it
was the programmer meant?

> That should be in the standards for compilers.
> I wouid be surprised if this were absent from standards committee
> agreements.
> The major point of Fortran is that there are no special reserved words, so
> semantics are everything.

What have reserved words got to do with anything? That's *syntax*, not
*semantics*.

Remind me what the error diagnostic requirements of Fortran 77 were?

[Terence]

First, I should agree with Ian Harvey.
I DID write 'semantics' when I was thinking of 'the meaning derived from the
syntax' - and so wrote the word for 'meaning' instead of 'syntax'. (There
are four languages in my household).
It is of course, errors in syntax that should be detected and reported by
the compiler.

Both the following are valid Fortan statements but belong two different
syntax families (one a do loop inititiation , and one an assignment)..
But a Latin-based language speaker (normally using a comma where english
would use a dot as a decimal point) might be forgiven for interchanging the
two, and instinctively reverse the semantics.

DO 1 I=1,7
DO 1 I=1.7

[Anton Shterenlikht]

I lost the plot.

I thought I understood the rules for the double
colon, but after following this discussion for while
I'm not sure anymore.

Do I understand correctly that the meanings of the two statements:

!234567
complex z=sqrt((-1,0))
and
complex :: z=sqrt((-1,0))

are different if compiled assuming the fixed form src?
In the second case a complex variable "z" is defined
and initialised to (-1,0). But what is the meaning
of the first specification?

Anton

[Harold Stevens]

In <ku2oid$98i$1...@speranza.aioe.org> Anton Shterenlikht:

[Snip...]

> complex z=sqrt((-1,0))

I think that is compiled under fixed form as

complexz=sqrt((-1,0))

which defines "complexz" (implicitly real), not "z" (:: complex).

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

[Dick Hendrickson]

The statement is an assignment statement (not a declaration statement)
which (at "run-time") assigns the value sqrt( (-1.0, 0.0) ) to a
variable named "complexz" which is implicitly declared to be a real
variable.

It's hard to see because it relies on a combination of several of
Fortran's worst features.

Dick Hendrickson

[dpb]

On 8/9/2013 7:50 AM, Anton Shterenlikht wrote:
> I lost the plot.
>
> I thought I understood the rules for the double
> colon, but after following this discussion for while
> I'm not sure anymore.
>
> Do I understand correctly that the meanings of the two statements:
>

> and
> !234567
> complex z=sqrt((-1,0))

> complex :: z=sqrt((-1,0))
>
> are different if compiled assuming the fixed form src?
> In the second case a complex variable "z" is defined
> and initialised to (-1,0). But what is the meaning
> of the first specification?

Remember that in fixed-form source blanks are insignificant; hence the
first is the same as if it were written

!234567
complexz = sqrt((-1,0))

Consequently, there's a default REAL variable COMPLEXZ attempting to be
initialized. A cast from the type of the intrinsic result to that of
the target variable would happen transparently (w/ a warning, perhaps;
not positive if that's actually required, either).

In free-form source, blanks _ARE_ significant. So, it's not really the
'::' that's the trigger, it's the source form. But, it would take the
colons to make the meaning since the blanks go away in parsing.

But, unless they've been expanded since F95, the SQRT() intrinsic isn't
allowable in an initialization expression; perhaps that has been relaxed
in later revisions.

--

[robin....@gmail.com]

On Friday, August 9, 2013 10:50:21 PM UTC+10, Anton Shterenlikht wrote:
> I lost the plot. I thought I understood the rules for the double colon, but after following this discussion for while I'm not sure anymore. Do I understand correctly that the meanings of the two statements: !234567 complex z=sqrt((-1,0)) and complex :: z=sqrt((-1,0)) are different if compiled assuming the fixed form src? In the second case a complex variable "z" is defined and initialised to (-1,0). But what is the meaning of the first specification? Anton

The second one might initialize Z to (0, -1), not (-1, 0).
(fatal error on F95 compiler)
The first one initializes COMPLEXZ to 0.

[glen herrmannsfeldt]

Dick Hendrickson <dick.hen...@att.net> wrote:
> On 8/9/13 7:50 AM, Anton Shterenlikht wrote:
>> I lost the plot.

>> I thought I understood the rules for the double
>> colon, but after following this discussion for while
>> I'm not sure anymore.

>> Do I understand correctly that the meanings of the two statements:

>> !234567
>> complex z=sqrt((-1,0))
>> and
>> complex :: z=sqrt((-1,0))

>> are different if compiled assuming the fixed form src?
>> In the second case a complex variable "z" is defined
>> and initialised to (-1,0). But what is the meaning
>> of the first specification?

> The statement is an assignment statement (not a declaration
> statement) which (at "run-time") assigns the value
> sqrt( (-1.0, 0.0) ) to a variable named "complexz" which is
> implicitly declared to be a real variable.

> It's hard to see because it relies on a combination of several of
> Fortran's worst features.

It is easy to see, though, that updating the standard and keeping
the the meaning unambiguous isn't so easy.

complex z

and

complex :: z

both declare a variable in either fixed or free form.

The IBM Fortran IV (and I believe also VS Fortran) allow
initializing on declarations with syntax similar to the DATA
statement:

complex z/(0.,-1.)/

this non-standard form might be accepted by some popular compilers.

(I believe the VAX/VMS compilers, and so likely their descendants,
also accept this.)

-- glen

[Ian Harvey]

On 2013-08-10 1:03 AM, dpb wrote:
> But, unless they've been expanded since F95, the SQRT() intrinsic isn't
> allowable in an initialization expression; perhaps that has been relaxed
> in later revisions.

It has been relaxed.

One which tripped up one of my compilers, as recently as two years back.
As the first line in a program unit:

INTEGER ELEMENTAL FUNCTION NAME(10)

I was trying to write a lexer/parser for this myself at the time. In
the comments for the resulting code I can see this resulted in a 40 line
diatribe about the evils of fixed form source.

[robert....@oracle.com]

On Friday, August 9, 2013 2:50:08 PM UTC-7, Ian Harvey wrote:
>
> One which tripped up one of my compilers, as recently as two years back.
> As the first line in a program unit:
>
> INTEGER ELEMENTAL FUNCTION NAME(10)
>
> I was trying to write a lexer/parser for this myself at the time. In
> the comments for the resulting code I can see this resulted in a 40 line
> diatribe about the evils of fixed form source.

I am surprised a compiler would have trouble with such a statement as recently as two years ago. Your example is one that, in a slightly simplified form, Fortran compilers have had to handle for about three decades. To have the problem, the compilers had to allow long names, but most FORTRAN 77 compilers did.

The UNIX f77 compilers handled a slightly more complicated case. They allowed a CHARACTER function to specify the length of the character value to be returned after the function name. An example is

CHARACTER FUNCTION NAME*(10)()

That syntax is not allowed by the FORTRAN 77 standard, but many compilers accepted it.

I recall a paper that showed many problems related to tokenizing FORTRAN 77 code and how to solve them, but I was not able to find it online.

Bob Corbett

[Ian Harvey]

On 2013-08-10 12:52 PM, robert....@oracle.com wrote:
> On Friday, August 9, 2013 2:50:08 PM UTC-7, Ian Harvey wrote:
>>
>> One which tripped up one of my compilers, as recently as two years
>> back. As the first line in a program unit:
>>
>> INTEGER ELEMENTAL FUNCTION NAME(10)
>>
>> I was trying to write a lexer/parser for this myself at the time.
>> In the comments for the resulting code I can see this resulted in a
>> 40 line diatribe about the evils of fixed form source.
>
> I am surprised a compiler would have trouble with such a statement as
> recently as two years ago. Your example is one that, in a slightly
> simplified form, Fortran compilers have had to handle for about three
> decades. To have the problem, the compilers had to allow long names,
> but most FORTRAN 77 compilers did.

To be fair it might have been something that got broken when changes to
the compiler were made for Fortran 95 (assuming here the compilers
lineage extended back that far, which I'm pretty sure it did.)

> The UNIX f77 compilers handled a slightly more complicated case.
> They allowed a CHARACTER function to specify the length of the
> character value to be returned after the function name. An example
> is
>
> CHARACTER FUNCTION NAME*(10)()
>
> That syntax is not allowed by the FORTRAN 77 standard, but many
> compilers accepted it.
>
> I recall a paper that showed many problems related to tokenizing
> FORTRAN 77 code and how to solve them, but I was not able to find it
> online.

The CHARACTER*xx type specifier also gave me grief at one stage. In the
absence of context CHARACTER * 10D0 could be a declaration or it could
be an expression, which changes the tokenization of the 10D0 thing.
Consequently I despise that archaic form. I was a bit disappointed to
see proposals for it to be brought back to life.

[robert....@oracle.com]

On Friday, August 9, 2013 8:49:31 PM UTC-7, Ian Harvey wrote:
> On 2013-08-10 12:52 PM, robert....@oracle.com wrote:

> > The UNIX f77 compilers handled a slightly more complicated case.
> > They allowed a CHARACTER function to specify the length of the
> > character value to be returned after the function name. An example
> > is
> >
> > CHARACTER FUNCTION NAME*(10)()
> >
> > That syntax is not allowed by the FORTRAN 77 standard, but many
> > compilers accepted it.
>

> The CHARACTER*xx type specifier also gave me grief at one stage. In the
> absence of context CHARACTER * 10D0 could be a declaration or it could
> be an expression, which changes the tokenization of the 10D0 thing.
> Consequently I despise that archaic form. I was a bit disappointed to
> see proposals for it to be brought back to life.

The CHARACTER*n form, where n is a string of digits, is obsolescent, not deleted. As a practical matter, Fortran compilers need to handle star-typing regardless of what the standard says, so I do not see star-typing for the CHARACTER type or any other intrinsic type going away soon.

Star-typing is among the easiest cases to tokenize. If a statement starts with a string of letters and digits followed by an asterisk, it is either an instance of star-typing or it is a malformed statement. Given that, a Fortran lexical analyzer does not need to look beyond the asterisk to recognize the tokens. If the first character following the asterisk is a digit, the lexical analyzer needs to treat it and any subsequent digits as an integer.

There are cases where Fortran is hard to tokenize. FORMAT statements and READ statements are bad. Some common nonstandard extensions, such as the TYPE statement for writing, do not play well with some of the syntax added to the language since FORTRAN 77.

Bob Corbett

[Ian Harvey]

That might be true "soon" (?) ... but consider in fixed form with F2008
as originally published:

CHARACTER * 80D0 = 'pointer function reference is a variable!'

where a variable named CHARACTER is of derived type and there is a
defined operation in scope for multiplication of an object of that
derived type by a REAL that has a pointer result (in this case, perhaps
also of character type).

[Dick Hendrickson]

On 8/10/13 6:08 AM, robert....@oracle.com wrote:
> On Friday, August 9, 2013 8:49:31 PM UTC-7, Ian Harvey wrote:
>> On 2013-08-10 12:52 PM, robert....@oracle.com wrote:
>
>>> The UNIX f77 compilers handled a slightly more complicated case.
>>> They allowed a CHARACTER function to specify the length of the
>>> character value to be returned after the function name. An example
>>> is
>>>
>>> CHARACTER FUNCTION NAME*(10)()
>>>
>>> That syntax is not allowed by the FORTRAN 77 standard, but many
>>> compilers accepted it.
>>
>> The CHARACTER*xx type specifier also gave me grief at one stage. In the
>> absence of context CHARACTER * 10D0 could be a declaration or it could
>> be an expression, which changes the tokenization of the 10D0 thing.
>> Consequently I despise that archaic form. I was a bit disappointed to
>> see proposals for it to be brought back to life.
>
> The CHARACTER*n form, where n is a string of digits, is obsolescent, not deleted. As a practical matter, Fortran compilers need to handle star-typing regardless of what the standard says, so I do not see star-typing for the CHARACTER type or any other intrinsic type going away soon.
>
> Star-typing is among the easiest cases to tokenize. If a statement starts with a string of letters and digits followed by an asterisk, it is either an instance of star-typing or it is a malformed statement. Given that, a Fortran lexical analyzer does not need to look beyond the asterisk to recognize the tokens. If the first character following the asterisk is a digit, the lexical analyzer needs to treat it and any subsequent digits as an integer.
>

It's more amusing if the compiler also supports the old Hollerith. A
compiler I once worked on got caught by things like
REAL*4 HENRY

The problem was that we eliminated Hollerith literally at the card image
level to make subsequent parsing easy. It was straightforward to fix;
but darn hard for a user to diagnose from the error messages.

Dick Hendrickson

[William Clodius]

<robin....@gmail.com> wrote:
> On Friday, August 9, 2013 10:50:21 PM UTC+10, Anton Shterenlikht wrote:
> > I lost the plot. I thought I understood the rules for the double colon,
> > but after following this discussion for while I'm not sure anymore.
> > Do I understand correctly that the meanings of the two statements:
> >!234567
> > complex z=sqrt((-1,0)) and
> > complex :: z=sqrt((-1,0))
> > are different if compiled assuming the fixed form src? In the second
> > case a complex variable "z" is defined and initialised to (-1,0). But
> > what is the meaning of the first specification? Anton
>
> The second one might initialize Z to (0, -1), not (-1, 0).
> (fatal error on F95 compiler)
> The first one initializes COMPLEXZ to 0.

The second one should initialize z to (0, 1), that is the principle
square root of (-1, 0).

[William Clodius]

In both cases sqrt((-1,0)) will return the principle square root of (-1,
0), i.e., (0., 1.). In the first case the assignment to the real value
complexz implicitly looses the imaginary part and complexz is assigned
the value zero. In the second case the complex variable z is initialized
to the value (0., 1.).

[William Clodius]

First as Ian Harvey notes reserved words are a trivial aspect of syntax.

Syntax is easy. Compilers must be able to interpret (parse) the
syntactic structure of a program before they are able to interpret its
semantics. The current syntactic structure of Fortran is well enough
defined that they can and do provide adequate error messages if they
cannot parse a program. However fixed form makes it particularly easy
for some forms of syntactic errors to still result in a syntactically
valid program. The often noted DO loop error (exchanging a '.' for a
',') first reported for the ground based Mercury orbital software is one
example, but so is the real variable complexz in the example Robin
complains about.

Semantics is much harder than syntax. It is common for compilers to
spend several orders of magnitude more time in the other stages of
compilation than they do in lexing and parsing the program. This
complexity makes it intrinsically hard to define semantic errors in a
form that can be systematically incorporated into the compiler and
runtime. Richard Maine gave some examples that can be caught by the
runtime, but for example if I have code of the form

x = 0
z = 1
...
z = z + 1

and being dyslexic I meant to enter
z = x + 1

that is a semantic error in the code (its meaning isn't what was
intended) and there is no way a compiler will detect this.

In the current environment, fixed form is almost invariably historic
F77, F66, Fortran IV code. Processors of that era almost invariably by
default initialized all variables (not explicitly initialized to other
values) to zero, and programmers of that era took advantage of that to
simplify their code, and did not know enough of the standards to know
that that made their code illegal. Uninitialized variables are endemic
in such codes. Most of the time this is harmless, by far the most common
initialization value is zero, but absent the equivalent of IMPLICIT NONE
it can hide typos.

The implicit interfaces F77 & F66 style code makes it impractical to
detect uninitialized variables, without a large runtime cost, though I
believe that WatIV did claim to do so. In the example that motivated
this tread, the lack of initialization of the z in the write statement
is relatively obvious, but if z were passed uninitialized to a
subroutine that expected z to be initialized, the independent
compilation model of that type of code made it impractical to detect
uninitialized variables without a large inccrease in the runtime. The
explicit interfaces of F90 make it more practical to statically detect
uninitialized variables, but if the initialization is determined by say
a seriees of if states, then the analysis can become equivalent to the
halting problem. For such cases reporting the vraible by static analysis
might be a false positive, while not reporting it might be a false
negative. Reliable detection can only be done at runtime. This in turn
requires associating with each potentially uninitialized variable a flag
indicating whether it has been defined, setting the flag when
initialized, and checking the flag when the variable must have a defined
value, e.g. as the argument to a write statement, or appearance on the
right hand side of an assignment.. Most Fortran programmers would not
accept the runtime cost.

[William Clodius]

FWIW I forgot tha t by initializing floating point entities to
signalling NaNs the flag can be internal to the entities. however that
would not help with the code

complex i=sqrt((-1,0))
print *,i
print *,cmplx(i,kind(1.d0))
end

where now the typo results in an uninitialized integer variable.

[robin....@gmail.com]

On Friday, August 9, 2013 7:55:59 PM UTC+10, Ian Harvey wrote:
> On 2013-08-09 4:48 PM, Terence wrote:
>
> > Apart from feeling that Robin is correct as the exchange occured, due to
> > incomplete available diagnostics being applied/allowed on the various
> > testings of the code, as he suggested might be happening, Robin's final
> > observation on the critism is the whole point:-
>
> >> So you are saying that the standards people can't be bothered
> >> putting in a statement that compilers are required to diagnose
> >> semantic errors, etc.
>
> > Please don't tell me that's true!
> > Semantic errors must be noted by the compiler.
>
> Lets hit google. "Semantic error - an error in logic or arithmetic that
> must be detected at run time."

You need to be careful using google for definitions.

In relation to compilers, a semantic error is an error in the meaning of a
statement as written.
It most certainly is NOT something that MUST or CAN ONLY BE be detected at run

time.

> An error in meaning. That is, the program means something, but that
> something is not what the programmer intended.

Certainly an error in meaning, but it is a violation of the rules for
writing a statement.

Here's an example:

program semantics
implicit none
integer k
call sub (k)
print *, k
contains
subroutine sub (x)
implicit none
real x
x = 3
end subroutine sub
end program semantics

> How can a *compiler*, in the general case, detect an error that occurs
> at *run time*?

Obviously a compiler usually can't; that's part of the run-time.

> How can the compiler, in the general case, know what it
> was the programmer meant?

No compiler can.
However, the semantics error to which I referred are those made
in the writing of a statement. (see example above)
These can be detected during compilation.

[Dick Hendrickson]

> The implicit interfaces F77& F66 style code makes it impractical to

> detect uninitialized variables, without a large runtime cost, though I
> believe that WatIV did claim to do so. In the example that motivated
> this tread, the lack of initialization of the z in the write statement
> is relatively obvious, but if z were passed uninitialized to a
> subroutine that expected z to be initialized, the independent
> compilation model of that type of code made it impractical to detect
> uninitialized variables without a large inccrease in the runtime. The
> explicit interfaces of F90 make it more practical to statically detect
> uninitialized variables, but if the initialization is determined by say
> a seriees of if states, then the analysis can become equivalent to the
> halting problem. For such cases reporting the vraible by static analysis
> might be a false positive, while not reporting it might be a false
> negative. Reliable detection can only be done at runtime. This in turn
> requires associating with each potentially uninitialized variable a flag
> indicating whether it has been defined, setting the flag when
> initialized, and checking the flag when the variable must have a defined
> value, e.g. as the argument to a write statement, or appearance on the
> right hand side of an assignment.. Most Fortran programmers would not
> accept the runtime cost.

Fortran has the other problem that variables can become undefined at
run-time. Fortran 08 has a list of 18 bad things (and some have
sub-bullets). Read statements that fail, messing around with pointers
and targets, storage association (EQUIVALENCE, COMMON), function
side-effects, etc. These are probably untraceable at run-time with any
reasonable amount of overhead.

Dick Hendrickson

[robin....@gmail.com]

On Sunday, August 11, 2013 3:04:59 PM UTC+10, William Clodius wrote:

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

> The second one should initialize z to (0, 1), that is the principle
> square root of (-1, 0).

Correct.

[robin....@gmail.com]

On Sunday, August 11, 2013 3:05:00 PM UTC+10, William Clodius wrote:

> In both cases sqrt((-1,0)) will return the principle square root of (-1,

.. the principal square root of ...

[robin....@gmail.com]

But it not a semantic error of the type to which I referred.
The kind of error (z = z + 1 in place of z = x + 1) is not normally
described as a semantics error, but is a programming error, pure and simple.

>
> In the current environment, fixed form is almost invariably historic
> F77, F66, Fortran IV code. Processors of that era almost invariably by
> default initialized all variables (not explicitly initialized to other
> values) to zero,

Not in my experience.

> and programmers of that era took advantage of that to
> simplify their code,

You'd scarcely call initialization to zero a "simplificiation of their code"
because it adds a trivial line, e.g., "k = 0" to the code,
and in some cases, no extra lines.

> and did not know enough of the standards to know
> that that made their code illegal.

It had little or nothing to with standards.
Failure to initialize to whatever was usually an oversight by the programmer.

> Uninitialized variables are endemic
> in such codes. Most of the time this is harmless, by far the most common
> initialization value is zero, but absent the equivalent of IMPLICIT NONE
> it can hide typos.
> The implicit interfaces F77 & F66 style code makes it impractical to
> detect uninitialized variables, without a large runtime cost, though I
> believe that WatIV did claim to do so.

It was called WATFIV. WATFOR did the same.
The run-time cost was trivial, just as it is now.

> In the example that motivated
> this tread, the lack of initialization of the z in the write statement
> is relatively obvious, but if z were passed uninitialized to a
> subroutine that expected z to be initialized, the independent
> compilation model of that type of code made it impractical to detect
> uninitialized variables without a large inccrease in the runtime.

It was done in WATFOR and WATFIV at trivial cost.
I think that PL/C also did it, again at trivial cost.

> The
> explicit interfaces of F90 make it more practical to statically detect
> uninitialized variables, but if the initialization is determined by say
> a seriees of if states, then the analysis can become equivalent to the
> halting problem.

There are other ways to detect uninitialized variables besides flow analyses.

> For such cases reporting the vraible by static analysis
> might be a false positive, while not reporting it might be a false
> negative. Reliable detection can only be done at runtime. This in turn
> requires associating with each potentially uninitialized variable a flag
> indicating whether it has been defined, setting the flag when
> initialized, and checking the flag when the variable must have a defined
> value, e.g. as the argument to a write statement, or appearance on the
> right hand side of an assignment.. Most Fortran programmers would not
> accept the runtime cost.

The run-time cost is, of course, trivial.

IIRC WATFOR and WATFIV stored a specific value in a variable.
E.g., for integer variables, -2147483648; the test involved merely
a trivial arithmetic left shift, causing an immediate overflow.

[robin....@gmail.com]

On Monday, August 12, 2013 12:12:21 AM UTC+10, William Clodius wrote:

> FWIW I forgot tha t by initializing floating point entities to
> signalling NaNs the flag can be internal to the entities. however that
> would not help with the code
>
> complex i=sqrt((-1,0))
> print *,i
> print *,cmplx(i,kind(1.d0))
> end
>
> where now the typo results in an uninitialized integer variable.

That error in the original code was detected by my compiler
at compile time.
I expect that the case for integer would also be similarly detected.

[robin....@gmail.com]

On Monday, August 12, 2013 1:41:41 AM UTC+10, Dick Hendrickson wrote:

> Fortran has the other problem that variables can become undefined at
> run-time. Fortran 08 has a list of 18 bad things (and some have
> sub-bullets). Read statements that fail, messing around with pointers
> and targets, storage association (EQUIVALENCE, COMMON), function
> side-effects, etc. These are probably untraceable at run-time with any
> reasonable amount of overhead.

Whether by flags or speciall values, its trivial to set such a variable
to undefined status, at run time (simple transfer instruction).

[Dan Nagle]

Hi,

On 2013-08-11 15:40:01 +0000, robin....@gmail.com said:

> You need to be careful using google for definitions.

OK, I'll check several sites found by Google. How 'bout

http://stackoverflow.com/questions/7849684/what-is-semantic-errors-in-c-language-give-some-examples


http://en.wikipedia.org/wiki/Logic_error

http://www.thefreedictionary.com/semantic+error

This is three of the top six when "programming semantic error"
is the input to Google.

> In relation to compilers, a semantic error is an error in the meaning of a
> statement as written.
> It most certainly is NOT something that MUST or CAN ONLY BE be detected at run
> time.

This site (on the first page of the above Google response) tries
to distinguish syntax error from semantic error:

http://au.answers.yahoo.com/question/index?qid=20100305162926AAFQ1C7

> Certainly an error in meaning, but it is a violation of the rules for
> writing a statement.

This one disagrees (again, the first page of the above Google query)

http://www.pcmag.com/encyclopedia/term/51088/semantic-error

My admittedly QUAD survey places robin....@gmail.com outside the orthodox.

--
Cheers!

Dan Nagle

[Richard Maine]

Dick Hendrickson <dick.hen...@att.net> wrote:

> Fortran has the other problem that variables can become undefined at
> run-time. Fortran 08 has a list of 18 bad things (and some have
> sub-bullets). Read statements that fail, messing around with pointers
> and targets, storage association (EQUIVALENCE, COMMON), function
> side-effects, etc. These are probably untraceable at run-time with any
> reasonable amount of overhead.

I might note that there are many cases where the reason the standard
says something is undefined is specifically to allow for different
compilers to have different implementations that would give different
results. Sometimes that's to allow for compiler-specific optimizations.
In other cases, it just acknowledges hardware differences. A simple
example is the way that a variable becomes undefined when an
ewuivalenced variable of a different type is defined; that mostly
acknowledges hardware differences in bit-level data representations.

It would be silly and counterproductive to have the standard say that a
particular implementation behavior (detection of the event and
generation of an error message) was required in order to allow for
multiple implementations. Perhaps more to the point, since there are
posters who seem to have drastically different notions than I do about
what would be silly and counterproductive, the standard categorically
does not require diagnostics in such cases.

This is not because of some oversight or laziness on the part of the
standard writers. It was considered and deliberate. One is free, of
course, to dislike the decision.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Gordon Sande]

The WatFor for IBM/7044 used a hardware hack of initializing to bad parity
and then trapping parity errors as undefined variables. No runtime overhead
as the parity checking was in hardware and experience showed that real parity
errors were so rare that it was safe to misuse them for this new purpose.

When WatFor was redone for IBM/360 Model XX this trick did not work and
they had to work hard to keep what had proven to be a very useful feature.
The overhead became noticable if one had a program long enough to measure
the time. There were enough gotchas in using WatFor that running large
programms was rare. The most blatent issue was that you needed the whole
thing in one source file. WatFiv was the follow-on with character variables
and other stuff.

The common WatFor mode was cafeteria style where the 10 second job was run
instantly and printed by the time you got your card deck back. Intended for
student use. There would be a separate area with dedicated card reader, printer
and operators. Salford (now SiverFrost) served the same market.

[Dick Hendrickson]

It's not trivial. For something like

subroutine aaa (func, y, z)
external func
...
if (y .gt. z .or. func(y,z) > 0) some statement

func is an unknown (at compile time) external function. If the compiler
does short circuiting of the logical expression, then any variables that
might be defined by the function func become undefined. How do you
trace through func to find those variables? In modern Fortran, func
might access other routines via procedure pointers, and they might
access ....

Suppose func has code like
common array(100)
read 10, I
array(I) = 0

It's my belief that the function side effect rule only undefines the Ith
element, not the entire array. I don't believe it is possible for the
run-time system to set the Ith flag without taking a peek at unit 10.
And if unit 10 is connected to a resetting Geiger counter, the program
results will change.

I don't think it's possible to track undefindness in this case.

Dick Hendrickson

PS: I rewrote a couple of sentences a couple of times to try and avoid
any flame wars about what the true rules are for functions with
side-effects.

[John Harper]

William Clodius wrote:

> Anton Shterenlikht <me...@mech-cluster241.men.bris.ac.uk> wrote:
>
>> Do I understand correctly that the meanings of the two statements:
>>
>> !234567
>> complex z=sqrt((-1,0))
>> and
>> complex :: z=sqrt((-1,0))
>>
>> are different if compiled assuming the fixed form src?
>

> In both cases sqrt((-1,0)) will return the principle square root of (-1,
> 0), i.e., (0., 1.). In the first case the assignment to the real value
> complexz implicitly looses the imaginary part and complexz is assigned
> the value zero. In the second case the complex variable z is initialized
> to the value (0., 1.).

True in f2003. In f95 sqrt is not allowed in an initialization expression.

--
John Harper

[glen herrmannsfeldt]

William Clodius <wclo...@earthlink.net> wrote:

(snip)

> First as Ian Harvey notes reserved words are a trivial aspect of syntax.

(snip)

> In the current environment, fixed form is almost invariably historic
> F77, F66, Fortran IV code. Processors of that era almost invariably by
> default initialized all variables (not explicitly initialized to other
> values) to zero, and programmers of that era took advantage of that to
> simplify their code, and did not know enough of the standards to know
> that that made their code illegal.

One system I used to use initialized to X'81', which was very
negative for integers, very small and negative for floating
point, and 'a' for CHARACTER. Often good enough to find bugs
in programs, but not perfect. (That worked for static variables,
such as Fortran. It didn't help as much for dynamically allocated
variables in PL/I and such.)

> Uninitialized variables are endemic
> in such codes. Most of the time this is harmless, by far the most common
> initialization value is zero, but absent the equivalent of IMPLICIT NONE
> it can hide typos.

I tend to write the small programs for posts in fixed form.
Not for any good reason, though.

> The implicit interfaces F77 & F66 style code makes it impractical to
> detect uninitialized variables, without a large runtime cost, though I
> believe that WatIV did claim to do so.

WAVFIV initializes to X'81', and tests for it on all references.

In all except WRITE statements, such access is fatal. WRITE will
fill the field with 'U' characters, I believe print a message,
and continue. (Well, formatted write. I am not sure about unformatted
write.)

> In the example that motivated
> this tread, the lack of initialization of the z in the write statement
> is relatively obvious, but if z were passed uninitialized to a
> subroutine that expected z to be initialized, the independent
> compilation model of that type of code made it impractical to detect
> uninitialized variables without a large inccrease in the runtime. The
> explicit interfaces of F90 make it more practical to statically detect
> uninitialized variables, but if the initialization is determined by say
> a seriees of if states, then the analysis can become equivalent to the
> halting problem. For such cases reporting the vraible by static analysis
> might be a false positive, while not reporting it might be a false
> negative.

Java solves this by declaring false positives as true positives.
That is, the user is required to satisfy the compiler that all
scalar variables are initialized before use. Arrays are zero,
false, or null, as appropriate.

> Reliable detection can only be done at runtime. This in turn
> requires associating with each potentially uninitialized
> variable a flag indicating whether it has been defined, setting
> the flag when initialized, and checking the flag when the
> variable must have a defined value, e.g. as the argument to
> a write statement, or appearance on the right hand side of
> an assignment.. Most Fortran programmers would not
> accept the runtime cost.

For floating point, there might be a value that isn't otherwise used.

-- glen

[glen herrmannsfeldt]

Gordon Sande <Gordon...@gmail.com> wrote:

(snip)

> The WatFor for IBM/7044 used a hardware hack of initializing to bad parity
> and then trapping parity errors as undefined variables. No runtime overhead
> as the parity checking was in hardware and experience showed that real parity
> errors were so rare that it was safe to misuse them for this new purpose.

> When WatFor was redone for IBM/360 Model XX this trick did not work and
> they had to work hard to keep what had proven to be a very useful feature.
> The overhead became noticable if one had a program long enough to measure
> the time. There were enough gotchas in using WatFor that running large
> programms was rare. The most blatent issue was that you needed the whole
> thing in one source file. WatFiv was the follow-on with character variables
> and other stuff.

I once did it for a program about 2000 lines long.
That was 30 seconds to compile in Fortran H, about 2 seconds
for WATFIV. Using the smallest input data file I could find, I got
it to run in 30 seconds (what took about 2 for the Fortran H version).
With that, I found many array bounds errors that I otherwise missed.
Maybe some uninitialized variables, too.

But yes, it was rare.

-- glen

[Gordon Sande]

On 2013-08-12 10:04:33 +0000, glen herrmannsfeldt said:

> Gordon Sande <Gordon...@gmail.com> wrote:
>
> (snip)
>> The WatFor for IBM/7044 used a hardware hack of initializing to bad parity
>> and then trapping parity errors as undefined variables. No runtime overhead
>> as the parity checking was in hardware and experience showed that real parity
>> errors were so rare that it was safe to misuse them for this new purpose.
>
>> When WatFor was redone for IBM/360 Model XX this trick did not work and
>> they had to work hard to keep what had proven to be a very useful feature.
>> The overhead became noticable if one had a program long enough to measure
>> the time. There were enough gotchas in using WatFor that running large
>> programms was rare. The most blatent issue was that you needed the whole
>> thing in one source file. WatFiv was the follow-on with character variables
>> and other stuff.
>
> I once did it for a program about 2000 lines long.
> That was 30 seconds to compile in Fortran H, about 2 seconds
> for WATFIV.

WatFor was a compile-to-core system that did not need a linker. There
was no optimization and the generated code was straight forward. The
compiler and the program were in core at the same time so memory was
tight back when memory was expensive and small. So very fast compilation
with immediate execution of correct but slow code. Completely suitable
for its purpose.

2000 lines would be a full box of cards for a cafeteria service setup.
Small by other standards but huge for a student project on cards.

> Using the smallest input data file I could find, I got
> it to run in 30 seconds (what took about 2 for the Fortran H version).
> With that, I found many array bounds errors that I otherwise missed.
> Maybe some uninitialized variables, too.

Good thing you were not dependent on some binary library.

[glen herrmannsfeldt]

Gordon Sande <Gordon...@gmail.com> wrote:

(snip, I wrote)

>> I once did it for a program about 2000 lines long.
>> That was 30 seconds to compile in Fortran H, about 2 seconds
>> for WATFIV.

> WatFor was a compile-to-core system that did not need a linker. There
> was no optimization and the generated code was straight forward. The
> compiler and the program were in core at the same time so memory was
> tight back when memory was expensive and small. So very fast compilation
> with immediate execution of correct but slow code. Completely suitable
> for its purpose.

Well, this was some time later, when memory wasn't so small.
Actually, virtual on a 370/168, maybe 384K.

> 2000 lines would be a full box of cards for a cafeteria service setup.
> Small by other standards but huge for a student project on cards.

(snip)

> Good thing you were not dependent on some binary library.

WATFIV will read S/360 style object files, but not load modules.
The usual system libraries are load modules. If you have assembler
source, you can assemble them and use the object module.

-- glen

[William Clodius]

> > On Friday, August 2, 2013 4:37:51 PM UTC+10,
> > robert....@oracle.com wrote:
> >
> > >
> >
> > > > On Thursday, August 1, 2013 6:24:46 PM UTC-7,
> > > > robin....@gmail.com wrote:
> >
> > > >
> >
> > > > > > In a recent discussion on complex multiply, I tried:
> >
> > >
> >
> > > > > > complex z=sqrt((-1,0))
> >
> > > > > > print *,z
> >
> > > > > > print *,cmplx(z,kind(1.d0))
> >
> > > > > > end
> >
> > > > > >
> >
> > > > > > Forgetting the need for such colons in this case. The
> > > > > > program compiles and gives different results than with
> > > > > > the ::.
> >
> > > > > It shouldn't have compiled at all, with the error
> > > > > in the 3rd statement.
>
> > > > The third statement is standard conforming.
>
> > > No it's not.
>
> > Yes, it is. Glen said that he is using fixed form. In fixed form, the
> > first line is an assignment statement and type of the variable z in
> > the third line is REAL.The only aspect of the program that is not
> > standard conformant is that it references an undefined variable.
>
> In fixed source form, with the colons present,
> the program shouldn't have compiled at all, because the third
> statement is in error.
No it isn't see below,

>
> In fixed source form, there are two instances of
> referencing an undefined variable.
>
> > > In the case cited, Glen states that the code gives different
> > > results with the colons present.
>
> > He also said it compiles.
>
> He may be mistaken.
>
> > > With the colons present, z is COMPLEX.
> > > The code CANNOT compile.
>
> > Yet it did.
>
> If it did, the compiler is broken.
> For a complex first argument, the second argument
> MUST be omitted.
>
> > The Fortran standard is a permissive standard. Except in the cases
> > cited in the standard, a conforming processor is not required to
> > diagnose a usage in a program that is not standard conforming.
> > The standard explicitly allows a conforming processor to provide
> > intrinsic functions not specified in the standard.
>
> Use your common sense.
> For something that isn't standard-conforming,
> the compiler needs to issue an error message.
>
> > > > Because of the missing double colon in the first line, the type of
> > > > the variable z in the third line is REAL.
>
> > > You might _think_ so, but that is not so.
>
> > The Fortran standard does not agree with you.
>
> > > with the colons missing, compilation fails at line 1
> > > (two adjacent variables).
>
> > The first statement is a conforming assignment statement in fixed
> > form.
> >
> > > (Even in fixed source form, the error still is diagnosed, and the
> > > program is in error.)
>
> > There is no error if the program is compiled for fixed source form.
>
> There is at least one error. See previous line.
>
> > > > The intrinsic function cmplx is allowed to have mixed
> > > > INTEGER and REAL expressions as arguments.
> >
> > > That is so, but that isn't the case that Glen cites.
> >
> > > > When the colons are added, the third statement is not standard
> > > > conforming, but the error is not a syntax error or a constraint
> > > > violation.
>
> It's called a semantic error -- an error that
> every compiler needs to diagnose.

I had hoped to reply to Bob Corbett's posting and it would be a boost ot
my ego to catch him in a mistake, but my newsreader no longer lets me
reply to his message. You are wrong that it is a semantic error. The
third statement is standard conforming with the double colon in the
appropriate location in the first statemen. Since F90 a standard
conforming CMPLX function has to be able to accept a complex x
argument of any kind, and an optional KIND argument that in effect
determines the precision of the result. It has that property probably to
provide a relativley simple way to change the precision of complex
expressions without explicitly creating a temporary. The print
statement cf course can accept a complex argument of any kind.

As to the reasoning: from the F2008 standard:

----------

13.7.31 CMPLX (X [, Y, KIND])

Description. Conversion to complex type.

Class. Elemental function.

Arguments.
X shall be of type integer, real, complex, or bits.
Y (optional) shall be of type integer, real, or bits. If X is of type
complex, no actual argument shall correspond to Y.
KIND (optional) shall be a scalar integer initialization expression.

Result Characteristics. The result is of type complex. If KIND is
present, the kind type parameter is that specified by the value of
KIND; otherwise, the kind type parameter is that of default real type.

Result Value. If Y is absent and X is not complex, it is as if Y were
present with the value zero. If X is complex, it is as if X were real
with the value REAL (X, KIND) and Y were present with the value
AIMAG (X, KIND). CMPLX (X, Y, KIND) has the complex value
whose real part is REAL (X, KIND) and whose imaginary part is
REAL (Y, KIND).

----------

While the examples shown in the standard all show the CMPLX
intrinsic with a complex x and a KIND argument in the form
CMPLX(x, KIND=expression) the examples are not normative text.
To me the description reads that if complex argument is present and
there is an additional argument it must be scalar integer initialization
expression and if present it will be interpretted as a kind value, i.e.
the effective interfaces of this intrinsic are (in pseudo-code)

CMPLX(real[, real, kind])
CMPLX(real[, integer, kind])
CMPLX(real[, bits, kind])
CMPLX(integer[, real, kind])
CMPLX(integer[, [nteger, kind])
CMPLX(integer[, bits, kind])
CMPLX(bits[, real, kind])
CMPLX(bits[, integer, kind])
CMPLX(bits[, bits, kind])
CMPLX(complex[, kind])

The presence of the COMPLEX argument means that the presence
of the KIND= is not needed to disambiguate the last form. Because
the KIND= is not explicitly required by the standard, a conforming
implementation must accept the form without the KIND=.

Given that the standard doesn't show an example without the
KIND=, I suspect this argument would surprise some members
of the standards committez. However they have been surprised
in the past by the implications of the standard's wordings. Unless
the wording is inconsistent, unimplementable, obviously incomplete,
or non-normative a straightforward interpretation is to be used,
whatever the committee's intent. It appears that everyone except you
has compilers that accept the complex argument with a kind argument
without the KIND=, so I am not alone in interpretting this intrinsic
this way. You have not said what compiler you had that rejected this.
If its not horribly out of date, I suggest you submit a bug report.
> <snip>

[william...@gmail.com]

Posting using Google groups since this thread is no longer active in my newsreader. Any alert readers of my posting will note that it refers to an intrinsic BITS data type, which of course is not part of any Fortran standard. I made the mistake of using an early draft of F2008 as my source of the quote. It looks like they decided that that type was more trouble than it was worth.

[Gary Scott]

On 8/14/2013 11:01 PM, william...@gmail.com wrote:
> Posting using Google groups since this thread is no longer active in my newsreader. Any alert readers of my posting will note that it refers to an intrinsic BITS data type, which of course is not part of any Fortran standard. I made the mistake of using an early draft of F2008 as my source of the quote. It looks like they decided that that type was more trouble than it was worth.
>

It would be a wonderful addition...if they did it right...the approach
was all wrong.

[robin....@gmail.com]

On Monday, August 12, 2013 2:25:06 AM UTC+10, Dan Nagle wrote:

> My admittedly QUAD survey places ro...@gmail.com outside the orthodox.

The meaning of a semantic error is something that a first-year
computer science student understands.

[robin....@gmail.com]

On Monday, August 12, 2013 2:41:33 AM UTC+10, Gordon Sande wrote:

> The WatFor for IBM/7044 used a hardware hack of initializing to bad parity
> and then trapping parity errors as undefined variables. No runtime overhead
> as the parity checking was in hardware and experience showed that real parity
> errors were so rare that it was safe to misuse them for this new purpose.
>
> When WatFor

It's WATFOR.

> was redone for IBM/360 Model XX this trick did not work and
> they had to work hard to keep what had proven to be a very useful feature.
> The overhead became noticable if one had a program long enough to measure
> the time.

The extra run time taken (compared to IBM cimpilers) had little or nothing to do
with checks for uninitialised variables, which was trivial.
The extra run time was caused by the fact that there was no attempt at
optimisation.

> There were enough gotchas in using WatFor that running large
> programms was rare. The most blatent issue was that you needed the whole
> thing in one source file.

Which the programs usually were.

> WatFiv

The name was WATFIV.

> was the follow-on with character variables
> and other stuff.
>
> The common WatFor mode was cafeteria style where the 10 second job was run
> instantly and printed by the time you got your card deck back.

It was set up to run a number of FORTRAN programs one behind the other,
without any S/360 job control cards.

> Intended for student use.

For anyone's use, but especially for batched student jobs, because
the compiler remained in memory while the batch was run.

That avoided the sluggish S/360 Operating system, which required
a minimum of 80 seconds to run even a 'hello world' job.
About 30 seconds of that was linkedit time.
The same job in WATFOR took a second.

> There would be a separate area with dedicated card reader, printer
> and operators.

It didn't need a "separate area"; the same card reader/printer
was used for all jobs.

> Salford (now SiverFrost) served the same market.

The Salford compiler provided a version that was compile-and-run.
The Silverfrost compiler wasn't.

[robin....@gmail.com]

On Monday, August 12, 2013 11:02:52 PM UTC+10, Gordon Sande wrote:

> WatFor

WATFOR

> was a compile-to-core system that did not need a linker. There
> was no optimization and the generated code was straight forward. The
> compiler and the program were in core at the same time so memory was
> tight back when memory was expensive and small.

Ordinary memory was expensive, but LCS (large core store) wasn't.
Thus, memory wasn't tight on systems having LCS.

> So very fast compilation
> with immediate execution of correct but slow code. Completely suitable
> for its purpose.
>
> 2000 lines would be a full box of cards for a cafeteria service setup.
> Small by other standards but huge for a student project on cards.

Regardless of who it was for, a 2,000 line program would be put thru
WATFOR until a clean compilation was obtained.

If it had a long run time, it would usually have been put through
one of the IBM compilers.

If it was a new-ish program, execution of the program would also be put through
WATFOR, because it caught many errors that the IBM compilers missed.

[robin....@gmail.com]

Oh indeed it is in error.

In your "reasoning" below, you have ignored the actual syntax of CMPLX,
namely,
13.7.31 CMPLX (X [, Y, KIND]).

Either X is present by itself, or, it is present with both Y and KIND.

[Dick Hendrickson]

NO,that's not the meaning of the standardese. Both Y and KIND are
separately optional. If you want to have a KIND without a Y, then you
have to name it ala CMPLX( whatever, KIND=8). You need to look at the
definitions of procedure argument lists with optional arguments.
Basically, if you don't use argument names in the invocation list, you
need to list all of the arguments in order until the remaining
(optional) arguments aren't needed. If you want to skip some of the
intervening optional arguments, you need to use explicit name=thingo
syntax for the subsequent arguments.

So, the pre-F90 version of CMPLX, CMPLX (x,y), still works.

I think (some of) Bill's argument was wrong, but your comment is wronger. ;)

Dick Hendrickson