🚀 go-pugleaf

The advantage in having the iteration variable declared in a for
statement remain accessible is that you can test its value after
the end of the loop.

		-- Jonathan Shopiro

> The advantage in having the iteration variable declared in a for
> statement remain accessible is that you can test its value after
> the end of the loop.
> 
> 		-- Jonathan Shopiro

    As has been pointed out, the following construct commonly appears
in coding:
		for(i = 0; i < MAX_I; ++i)
			{
			    .
			    .
			    .
			}
		if(i >= MAX_I)
			<code 'cause FOR loop "fell through">

In the true spirit of language diddling, how about allowing "else"
statements to bind with "for"s as well as "if"s?  The "else" of
a "for" would be taken if the loop terminated "naturally".  That is,
the "else" of a "for" would be skipped if the loop was exited by means
of a "break" statement.  Of course, once you allow "for"s to have "else"s,
why deprive "while"s, and "do-while"s?  This is not a tenable solution
in C++, since it would break some existing C programs (unless "else"s bound
to "if"s more strongly than they did to "for"s :-)  Just a thought.  Pros?
Cons?  Gut-level feelings of revulsion?

{ihnp4|akgua|nsc}!zaiaz!rlb		-Ron Burk

In article <5334@alice.uUCp> shopiro@alice.UUCP writes:
>The advantage in having the iteration variable declared in a for
>statement remain accessible is that you can test its value after
>the end of the loop.

An alternative would be to have a 'for' expression - the same as a 'for'
statement except that it returns the value of the iteration variable on
exit.  This satisfies your requirement to have such information available
while also avoiding the unintuitive behaviour noted by the original poster.

Mind you, I'm not convinced that the value of an iteration variable is needed
often enough in time-critical code for either system to be required.  An 
assignment in the loop body will give this info when its needed.
-- 
	Dave Berry. CS postgrad, Univ. of Edinburgh		
					...mcvax!ukc!cstvax!db

In article <101@cstvax.UUCP> db@cstvax.UUCP (Dave Berry) writes:
> An alternative would be to have a 'for' expression - the same as a 'for'
> statement except that it returns the value of the iteration variable on
> exit.

	The trouble with all such suggestions is that there are too many
things that a loop *could* deliver, and for every application that would
make use of one such thing, there are equally worthy applications for all
the others.  Further, there is always a cogent objection.  For example,
you could return:

   a)	The value that the iteration variable would have on the next cycle
	[ie, the value that caused termination] -- but this could easily
	be > maxint.
   b)	The value it did have on the last cycle -- but there might not
	have been one.
   c)	The number of cycles -- but this could easily be > maxint [well,
	fairly easily].
   d)	Whatever the last obeyed controlled statement delivered -- but
	there might not have been one.
   e)	The collection of objects delivered by the controlled statements
	-- nice, but doesn't half fill up the stack!
   f,g,h,...)	Add to taste, depending on your favoured language.

	Better to have nothing than to spread such confusion!

							-- Andy Walker.

Several notes have mentioned using loop variables after the loop as
a reason for making:

	for (int i = ...)

equivalent to

	int i;
	for (i = ...)

It seems to me that if the loop variable is really needed after
the "for" statement, then the second form is just about as easy to
write and expresses the use of the variable much more clearly.

I consider the current semantics a real wart.  Actually, after programming
fairly intensively in C++ for a month or so, I feel that scoping in general
is the single weakest point of the language.  The way enumeration types
(and constants in general) are handled within classes is particulary
poor.  Are the scope issues going to be addressed more fully in
subsequent releases?

-- Jim Mayer					University of Rochester
(arpa) mayer@Rochester.ARPA			Department of Computer Science
(uucp) rochester!mayer				Ray P. Hylan Building
       (via allegra, decvax, or seismo)		Rochester, New York 14627

In article <224@tuck.nott-cs.UUCP> nott-cs!anw (Andy Walker) writes:
>In article <101@cstvax.UUCP> db@cstvax.UUCP (Dave Berry) writes:
>> An alternative would be to have a 'for' expression - the same as a 'for'
>> statement except that it returns the value of the iteration variable on
>> exit.

Not all "for" statements *have* an iteration variable.

>	The trouble with all such suggestions is that there are too many
>things that a loop *could* deliver, and for every application that would
>make use of one such thing, there are equally worthy applications for all
>the others.  Further, there is always a cogent objection.  For example,
>you could return:
>
>   a)	The value that the iteration variable would have on the next cycle
>	[ie, the value that caused termination] -- but this could easily
>	be > maxint.

If so, you've already got a problem (probably infinite loop).  Remember, a
"for" is just a glorified "while".

>...	Better to have nothing than to spread such confusion!

I ran into these same problems some years ago when designing a language with
statement-expression equivalence.  I concluded that a loop has a void value.

In C++, it's not so bad having statements which are not expressions, because
you can just make a one-statement inline function and use "return".

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint

> the "else" of a "for" would be skipped if the loop was exited by means
> of a "break" statement.  Of course, once you allow "for"s to have "else"s,
> why deprive "while"s, and "do-while"s?  This is not a tenable solution
> in C++, since it would break some existing C programs (unless "else"s bound
> to "if"s more strongly than they did to "for"s :-)  Just a thought.  Pros?
> Cons?  Gut-level feelings of revulsion?

I like it, however the semantics of the statement don't quite gibe with
the syntax if you use it the way you describe. How about this equivalence?

New Syntax		Equivalent Code (except for evaluations):

while(e)		if(e)
	s1			while(e)
else					s1
	s2		else
				s2

for(i; e; i)		i;
	s1		if(e)
else				for(; e; i)
	s2				s1
			else
				s2

...and so on. Of course, this doesn't address the problem of the value of
the iteration variable. Personally, I prefer to be able to test the value
of that variable directly. Of course I usually make my iteration variables
registers anyway, since most of the code I write these days is real-time
stuff...
-- 
-- Peter da Silva
-- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076

> In article <224@tuck.nott-cs.UUCP> nott-cs!anw (Andy Walker) writes:
> >In article <101@cstvax.UUCP> db@cstvax.UUCP (Dave Berry) writes:
> >> An alternative would be to have a 'for' expression - the same as a 'for'
> >> statement except that it returns the value of the iteration variable on
> >> exit.
> 
> Not all "for" statements *have* an iteration variable.
> 
> In C++, it's not so bad having statements which are not expressions, because
> you can just make a one-statement inline function and use "return".

How about going back to BCPL and allow *any* block to have a value that is
returned by "return" (or use the BCPL keyword "resultis")?

I have a question about C++: what is "cout << value"? I presume that's
supposed to print the value in an appropriate format, but I can't figure
why "cout". Why not "print value..."?
-- 
-- Peter da Silva
-- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076