[comp.lang.fortran] i++, i+=1, i=i+1

chris@mimsy.UUCP (Chris Torek) (09/15/88)

>In article <13547@mimsy.UUCP> I wrote:
>>I do suggest, though, that no one use `i = i + 1' to increment.  If you
>>dislike `++', use `i += 1'.  When you mean `add one to i', why not *say*
>>it?

In article <3568@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>'i = i + 1' _does_ say it!!!

Indeed, in a certain sense---if one examines the semantics and
considers the language definition, always, of course, keeping in mind
the actions and situations and possibilities, and remembering all there
is to contemplate upon, why, then, certainly---it does not say anything
other than what it should say, which is to say, not to do anything
other than to add one to i.

Have I, perhance, managed to communicate with these words, these
sentences, these paragraphs, the sense in which I mean to imply that
`add one to i' and `take i, add one, and put it back' are, while they
are certainly congruent in some aspects, and in ultimate true meaning
identical, not at all the same?

>Any compiler which generates different code for 'i = i + 1', 'i += 1',
>and 'i++' is a certifiably _stupid_ compiler.

Agreed.

>Those three examples are semantically _identical_, their syntactic difference
>is a textual convenience - at best.

Also agreed.  Convenience, however, makes all the difference.  I, as
a reader, would much rather see as an English description the phrase
`add 1 to i' than `evaluate i, evaluate the integer constant 1, add
the values together, and store the result in the location named by i'.
Likewise, I would much rather read `i += 1' than `i = i + 1'.  For
such a trivial expression, the difference in convenience is minimal.
But what about

	-- not in any particular language
	intensity(l1, II, l[I[1]]) += factors[Il[l1+I[II]]]

Here the notational conveniece is quite significant.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

jlg@lanl.gov (Jim Giles) (09/16/88)

From article <13566@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):
> Also agreed.  Convenience, however, makes all the difference.  I, as
> a reader, would much rather see as an English description the phrase
> `add 1 to i' than `evaluate i, evaluate the integer constant 1, add
> the values together, and store the result in the location named by i'.

My english description of 'i = i + 1' _is_ "add 1 to i".  the difference
between that and 'i += 1' is purely textual.  It's easy to write a
preprocessor to switch the later to the former.  Such a preprocessor
needn't have _any_ semantic knowledge of the target language.  It need
only look for '+='  and replace it with '= _X_' where _X_ is whatever
token preceeds the '+='.  In other words, as far as functionality
goes, '+=" doesn't do a damn thing.

J. Giles
Los Alamos

warner@hydrovax.nmt.edu (M. Warner Losh) (09/16/88)

In article <3629@lanl.gov>, jlg@lanl.gov (Jim Giles) writes...
>My english description of 'i = i + 1' _is_ "add 1 to i".  the difference
>between that and 'i += 1' is purely textual.  It's easy to write a
>preprocessor to switch the later to the former.  Such a preprocessor
>needn't have _any_ semantic knowledge of the target language.  It need
>only look for '+='  and replace it with '= _X_' where _X_ is whatever
>token preceeds the '+='.  In other words, as far as functionality
>goes, '+=" doesn't do a damn thing.

mild flame on

As Chris has already pointed out, += doesn't do much for you in terms of
functionality.  It is more convient to use this notation.  If you want
to get really technical, then you should be programming in Turing
machine logic, since it offers no more functionality than C or FORTRAN
or any modern computer language.  It has several probelms:  1) it is
totally gross and unclear and 2) it takes several pages to do what you
can do in FORTRAN or C in one line.  That is why we do things in C or
FORTAN, and not in Assmebler or Turning machine langues.

The standard usage in 'C' (meaning, this is how most 'C' programmers
program, not what *MUST* be done) is to use += or ++ .  There was a time
when += or ++ produced better code.  That is why they were introduced to
the language (I think, I haven't actually asked K&R).  Since they are in
wide spread use, must 'C' programmers know how to interpret these
strange symbols.  FORTRAN programmers will have some trouble here, since
there is no EXACT analog in FORTRAN.  This doesn't mean that they can't
learn how to read them, it just means that it is hard at first.

major flame on

Can we now get back to talking about FORTRAN, and what the damn committee
is doing to our FORTRAN?  Ppppppplease?

flame off

C isn't FORTRAN.  FORTRAN isn't C.

>J. Giles
>Los Alamos
--
Warner Losh
warner@hydrovax.nmt.edu		...!unmvax!nmtsun!warner%hydrovax
"I don't know what language they will be programming in in the year 2000,
 but it will be called FORTRAN." -- Some one else...
My spelling and views are my own.  Only the vowels have been changed....

bgg@pyrps5 (Ben Golding - R+D Australia) (09/16/88)

In article <3629@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
>							    the difference
> between that and 'i += 1' is purely textual.  It's easy to write a
> preprocessor to switch the later to the former.  Such a preprocessor
> needn't have _any_ semantic knowledge of the target language.

This is nonsense - it is not a "purely textual difference" if there are
side effects.  The "FORTRAN" statements:

	a(icomp(j)) += 1;

and

	a(icomp(j)) = a(icomp(j)) + 1;

are not purely textual substitutions if icomp is a function that
changes the value of j.

This distinction is particularly important in C where "i++" is commonly
used and produces rather different results if the expression is evaluated
twice.

	Ben Golding (bgg@yarra.oz.au)
	Pyramid Technology Corporation (Australia)

ags@h.cc.purdue.edu (Dave Seaman) (09/16/88)

In article <3629@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>My english description of 'i = i + 1' _is_ "add 1 to i".  the difference
>between that and 'i += 1' is purely textual.  It's easy to write a
>preprocessor to switch the later to the former.  Such a preprocessor
>needn't have _any_ semantic knowledge of the target language.  It need
>only look for '+='  and replace it with '= _X_' where _X_ is whatever
>token preceeds the '+='.  In other words, as far as functionality
>goes, '+=" doesn't do a damn thing.

If you apply your preprocessor to 

	x[i*f(j)+k*g(l)] += y

you get

	x[i*f(j)+k*g(l)] = x[i*f(j)+k*g(l)] + y

which is not the same expression at all, becauses it causes the the subscript 
to be evaluated twice.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu

mike@arizona.edu (Mike Coffin) (09/16/88)

From article <3629@lanl.gov>, by jlg@lanl.gov (Jim Giles):

> In other words, as far as functionality goes, '+=" doesn't do a damn
> thing. 
Well, actually it does.  I admit, this is a minor quibble, but
	x[rand()] += 1;
is not quite the same as
	x[rand()] = x[rand()] + 1;


-- 
Mike Coffin				mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2,ihnp4}!arizona!mike
Tucson, AZ  85721			(602)621-2858

chpf127@ut-emx.UUCP (J. Eaton) (09/16/88)

In article <3629@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <13566@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):
> > Also agreed.  Convenience, however, makes all the difference.  I, as
> > a reader, would much rather see as an English description the phrase
> > `add 1 to i' than `evaluate i, evaluate the integer constant 1, add
> > the values together, and store the result in the location named by i'.

    Certainly, since the second description, while complete, is rather
    wordy.  The first, while it is a convenient shorthand, isn't
    sufficient as a description [see below].

> My english description of 'i = i + 1' _is_ "add 1 to i".

    Hmmm.  Mine is:  `Huh?  This can't be.', or:  `No, I'm afraid
    that's false.'   Unless I know more about the rules of the
    language it doesn't really mean a whole lot (neither does ++,
    or +=, or even :-).

    Your description "add 1 to i" only takes care of the
    right hand side, and does nothing to explain what the heck the
    left hand side and the equals sign are doing.  I need to know more
    than "add 1 to i" to carry out all that's required by either C or
    Fortran;  I need the second description given above by Chris.
    But that's wordy, so I'll use a shorthand, i++ or i+=1 in C, or
    even i=i+1 if I happen to be using Fortran.

    In any case, as long as we've agreed on the rules, and have a
    sufficiently clear and unambiguous definition of them, we should
    be all right.  Is the real problem simply that someone in this
    discussion doesn't like the rules?


  J. Eaton                                        Not really doing anything
  UT Austin Department of Chemical Engineering              with chemicals.

jlg@lanl.gov (Jim Giles) (09/16/88)

From article <3976@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman):
> If you apply your preprocessor to 
> 	x[i*f(j)+k*g(l)] += y
> you get
> 	x[i*f(j)+k*g(l)] = x[i*f(j)+k*g(l)] + y
> which is not the same expression at all, becauses it causes the the subscript 
> to be evaluated twice.

No, it doesn't cause the subscript to be evaluated twice.  In Fortran
functions are not allowed to have side effects.  The compiler will
therefore recognize the subscript expressions as common subexpressions
and will evaluate only once.  One guy had rand() in his example of
subscript expressions - ever wonder why rand() isn't part of the Fortran
standard?  Ever wonder why most Fortran compilers warn against using
rand() more than once in the same expression?  This is why.

Actually an expression like RAND(1)+RAND(2) _will_ call the random generator
twice.  Fortran assumes the lack of side effects, but a function applied
to different arguments must be repeated for each different argument.
Ever wonder why rand() takes an argument which it ignores?

J. Giles
Los Alamos

chris@mimsy.UUCP (Chris Torek) (09/16/88)

>In article <13566@mimsy.UUCP> I wrote a nice flowery description
showing exactly why I say `i += 1' is superiour to `i = i + 1', and
described it as follows:
>>... I, as a reader, would much rather see as an English description the
>>phrase `add 1 to i' than `evaluate i, evaluate the integer constant 1,
>>add the values together, and store the result in the location named by i'.
Likewise, I would rather see `i += 1' than `i = i + 1'.

In article <3629@lanl.gov> jlg@lanl.gov (Jim Giles) answers:
>My english description of 'i = i + 1' _is_ "add 1 to i".  the difference
>between that and 'i += 1' is purely textual.

Very well.  Let us remove the `**' operator from FORTRAN, replacing it
with the `POWER' intrinsic.  The difference is purely textual.

>...  In other words, as far as functionality goes, '+=" doesn't do a
>damn thing.

Actually, it does, although it would not in FORTRAN.  In C, given

	int *pickone() { static int a, b; return (rand()&1 ? &a : &b); }

the expressions

	*pickone() += 1;

and

	*pickone() = *pickone() + 1;

mean very different things.  But this is irrelevant.

The key is that the C language has op= operators, so you can expect
anyone reading C code to be familiar with them.  Since they more
concisely express the intended result, you should use them.  The
FORTRAN languages do not have op= operators, and you cannot expect
anyone reading FORTRAN code to be familiar with them.  While they more
concisely express the intended result, you should not use them lest you
confuse the reader.

Similarly, the FORTRAN language has the `**' operator.  It more
concisely expresses exponentiation than C's `pow()' function.  It
should be used ... in FORTRAN, and not in C.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

ags@h.cc.purdue.edu (Dave Seaman) (09/16/88)

In article <3659@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>No, it doesn't cause the subscript to be evaluated twice.  In Fortran
>functions are not allowed to have side effects.  

May I suggest that you read the standard before making such statements?
At least one variety of side effect is explicitly permitted by the
standard.  I quote the last paragraph of Section 15.5.1, "Function
Subprogram and FUNCTION Statement":

	An external function in a function subprogram may define one or
	more of its dummy arguments to return values in addition to the
	value of the function.

So far I have not found any statements concerning other varieties of side
effects, either for or against.  I do note that section 15.5.3, "Function
Subprogram Restrictions", fails to mention any restrictions on side
effects.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu

gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (09/17/88)

In article <3659@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>
> [stuff deleted]
>
>No, it doesn't cause the subscript to be evaluated twice.  In Fortran
>functions are not allowed to have side effects.  The compiler will
>therefore recognize the subscript expressions as common subexpressions
>and will evaluate only once. [...]
>

VAX/VMS fortran doesn't work this way, even with math library functions
which are known to have no side-effects. if you write

	a = sin(x)
	b = sin(x)
	c = sin(x)

it will call sin() 3 times. anyone have any idea why they would do this?

Greg Lindahl                              internet:  gl8f@virginia.edu
U Va Dept. of Astronomy                   bitnet:    gl8f@virginia.bitnet

jlg@lanl.gov (Jim Giles) (09/17/88)

From article <1123@nmtsun.nmt.edu>, by warner@hydrovax.nmt.edu (M. Warner Losh):
> Can we now get back to talking about FORTRAN, and what the damn committee
> is doing to our FORTRAN?  Ppppppplease?
> 
> flame off
> 
> C isn't FORTRAN.  FORTRAN isn't C.

I agree. But a lot of the C supporters (and others) _seem_ to want to 
make Fortran more like C.  Why discuss C in the comp.lang.fortran group
at all except to compare features that _might_ be useful.  I think there
are a lot of things in C that might (with substantial modification) be
useful for the Fortran committee to consider.  I _KNOW_ that the committee
is considering pointers.  The point is that it is clearly undesireable
for some of the (most touted) C features to _ever_ make it into Fortran.

In light of this, it is perfectly valid to examine C features (good and
bad) in the Fortran group.  It is also valid, if you think a C feature is
bad, to say so and give reasons why.  Here are some features that _might_
be nice to see in Fortran:

1) Pointers - but _not_ the way C does them.

2) A preprocessor - but _not_ as an required part of the language.
   A supplimentary standard for a preprocessor could be devised which
   would complement the Fortran language without being a built-in part
   of it.

3) Exception handling - but, again, as a supplimentary standard.  The
   supplimentary standard would describe a set of library routines which
   would provide the necessary functionality.  And, again, without being
   a built-in part of the language itself.

If you have questions about what constitutes a supplimentary standard,
the Fortran 8x proposal (which has been effectively shot down) devoted
appendix A to the subject.  Supplimentary standards have the advantage
that they are free to be designed with more than _one_ language in mind.

The above list is in no way exhaustive.  But the main idea is to keep
an open (but not an empty) mind about features.  Without doubt, C has
a lot of very desireable properties.  Fortran should take note of these,
but without copying the undesireable ones (of which there are plenty).

J. Giles
Los Alamos

jlg@lanl.gov (Jim Giles) (09/17/88)

From article <13583@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):
> Very well.  Let us remove the `**' operator from FORTRAN, replacing it
> with the `POWER' intrinsic.  The difference is purely textual.

My major objection to the pow() intrinsic (as you well know if you read
the _long_ argument about it) was that C implements it inefficiently.
Exponentiation should be an in-line function (if the compiler is capable).
The C language design makes this impossible (pow() is an external, therefore
it must be possible for the user to substitute his own version at load time,
therefore it cannot be expanded in-line at compile time).  The ANSI C
standard will apparently address this.  A secondary objection is that
exponentiation is a mathematical operation for which mathematicians
and others have always had (and still expect) a shorthand syntax.
Assignment operator(s) have not this standing expectation from the
user community - so shorthand variants really are just textual sugar
for the few that _need_ such things.

J. Giles 

seanf@sco.COM (Sean Fagan) (09/17/88)

In article <3659@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <3976@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman):
>> If you apply your preprocessor to 
>> 	x[i*f(j)+k*g(l)] += y
>> you get
>> 	x[i*f(j)+k*g(l)] = x[i*f(j)+k*g(l)] + y
>> which is not the same expression at all, becauses it causes the the subscript 
>> to be evaluated twice.
>
[functions not allowed to return different values on the same input]
[also not allowed to have side-effects]

Wrong.  They can.  Also, with regards to side-effects, a FORTRAN function
can modify a COMMON variable, or, happy happy, its argument.  So what
happens when j and l change between the first and second calls of f() and
g(), respectively?  Are you saying that the compiler can just optimize
(incorrectly, I should add) the function calls into one function call?
Which means that, in order to do what the programmer wants, he has to use
temporary variables?

Didn't I see an article a while ago saying that FORTRAN was nice because you
didn't have to use temporary variables to get what you wanted evaluated
correctly?

>J. Giles
>Los Alamos


-- 
Sean Eric Fagan  | "Joy is in the ears that hear, not in the mouth that speaks"
seanf@sco.UUCP   |     -- Saltheart Foamfollower (S. R. Donaldson)
(408) 458-1422   | Any opinions expressed are my own, not my employers'.

jlg@lanl.gov (Jim Giles) (09/17/88)

From article <3979@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman):
> May I suggest that you read the standard before making such statements?
> At least one variety of side effect is explicitly permitted by the
> standard.  I quote the last paragraph of Section 15.5.1, "Function
> Subprogram and FUNCTION Statement":
> 
> 	An external function in a function subprogram may define one or
> 	more of its dummy arguments to return values in addition to the
> 	value of the function.
 

May I suggest that you read the standard before making such statements?
I had forgotten the above (that is, in fact, the only side effect
allowed explicitly).  But you seem to have forgotten the last paragraph
of Section 6.6.2, "Order of Evaluation of Functions":

      In a statement that contains more than one function
      reference, the value provided by each function reference
      must be independent of the order chosen by the processor for
      evaluation of the function references.

J. Giles
Los Alamos

ags@h.cc.purdue.edu (Dave Seaman) (09/18/88)

In article <3701@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
 [ After I quoted the standard to prove he was wrong about side effects]

>May I suggest that you read the standard before making such statements?
>I had forgotten the above (that is, in fact, the only side effect
>allowed explicitly).  But you seem to have forgotten the last paragraph
>of Section 6.6.2, "Order of Evaluation of Functions":
>
>      In a statement that contains more than one function
>      reference, the value provided by each function reference
>      must be independent of the order chosen by the processor for
>      evaluation of the function references.
>
Now, wait just a minute.  I have not forgotten anything.  I never said
that there were NO situatations in which side effects were disallowed.  I
was careful to say that I had found ONE instance in which side effects are
permitted by the standard.  This is already enough to prove my point that
side effects are not always forbidden.

You, after all, were claiming right up until you read my response that
there were NO situations in which side effects were allowed.

You said that it was not possible to implement a random number generator
in standard Fortran.

You said that allowing side effects is "an extension to the standard."

And now you are telling me that I am the one who needs to read the
standard?

Let me point out two things about the statement you quoted from the
standard.  If the intent was to rule out side effects altogether, then why
is that first clause there?  Why is the restriction so narrowly worded
that it applies only when there are multiple function calls in a
statement?  And why does it only rule out one particular category of side
effect (the ones that would affect the functions' returned values)?  It
does not even guarantee that it is safe to evaluate the subscript only
once in my example which started this discussion.  The function may
increment a variable in COMMON each time it is called.  This need not
affect the value returned by the function, but it certainly can affect
other parts of the program.

Judging by your latest reply, you apparently still believe that all side
effects other than the one I quoted are forbidden.  I claim the standard
says otherwise.  I do not have the standard in front of me as I write
this, but I can paraphrase some things that I read two days ago.  My
evidence:

  1.  The section on statement functions contains a restriction that is
      somewhat similar in spirit to the one you quoted:  If a statement
      function calls an external function, the external function may not
      alter any of the statement function arguments.  Again, the reason
      for the restriction is clear.  Again, the restriction was worded as
      narrowly as possible.  The clear implication is that whatever is not
      specifically prohibited in the standard is allowed (at least as far
      as side effects are concerned).  More on this in a moment.

  2.  The section that spells out restrictions on external functions fails
      to restrict side effects in any way, as I previously noted.

  3.  I remember reading a statement to the effect that "whatever is
      allowed in external subroutines is also allowed in external
      functions, with the following two exceptions ...."  I looked up the
      cited exceptions, and neither of them concerns side effects.  Since
      side effects are permitted in subroutines, it looks very much as if
      they are permitted in functions as well.  I will look up the
      paragraph number for this if you don't believe me, but you shouldn't
      have any trouble finding it yourself.  It is obviously in the
      chapter that talks about external functions.

In short, I claim that side effects are normally legal in Fortran
functions, and I believe the burden of proof is on you to show otherwise.
Isolated special cases do not count.  It is the general rule that I am
concerned with.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu

peter@ficc.uu.net (Peter da Silva) (09/19/88)

In article <3697@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> Exponentiation should be an in-line function (if the compiler is capable).

Agreed...

> The C language design makes this impossible (pow() is an external, therefore
> it must be possible for the user to substitute his own version at load time,
> therefore it cannot be expanded in-line at compile time).

This is not true. Just because something in 'C' has the form of a function
does not mean it is forced to be a function:

	getchar()
	min()/max() on many machines
	feof()
	isprint()

	All of these are macros. Many compilers implement strcpy() and
related functions inline just because this gives a speed advantage on
certain types of problems (such as dhrystone :->).

> A secondary objection is that
> exponentiation is a mathematical operation for which mathematicians
> and others have always had (and still expect) a shorthand syntax.

This syntax is, however, not the one Fortran uses. The mathematical syntax
for exponentiation is actually not displayable in ASCII text.
-- 
Peter da Silva  `-_-'  Ferranti International Controls Corporation.
"Have you hugged  U  your wolf today?"            peter@ficc.uu.net

jlg@lanl.gov (Jim Giles) (09/20/88)

From article <1267@scolex>, by seanf@sco.COM (Sean Fagan):
> [functions not allowed to return different values on the same input]
> [also not allowed to have side-effects]
> 
> Wrong.  They can.  Also, with regards to side-effects, a FORTRAN function

Please read _all_ of section 6.6 of the Fortran 77 manual.  There are numerous
constraints on the side effects of functions contained therein.  Admittedly,
these are the _only_ constraints on side effects of Fortran functions,
but they cover the case under present consideration _completely_.

J. Giles
Los Alamos

thompson@batcomputer.tn.cornell.edu (Steve Thompson) (09/21/88)

In article <561@hudson.acc.virginia.edu> gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) writes:
	VAX/VMS fortran doesn't work this way, even with math library functions
	which are known to have no side-effects. if you write
		a = sin(x)
		b = sin(x)
		c = sin(x)
	it will call sin() 3 times. anyone have any idea why they would do this?

I couldn't believe this when I saw it, so I checked it on my VMS V4.7/
FORTRAN V4.8 system. Sin(x) does get called only ONCE, as you can
easily verify by looking at the machine code listing.