[comp.lang.misc] FOR loops

jgm@K.GP.CS.CMU.EDU (John Myers) (03/12/88)

In article <1301@eneevax.UUCP> noise@eneevax.umd.edu.UUCP (Johnson Noise) writes:
>In article <1345@daimi.UUCP> erja@daimi.UUCP (Erik Jacobsen) writes:
>
>>This problem does not exist with WHILE/REPEAT-loops, and removing
>>the FOR-loop from a language is one effective way of making it
>>cleaner.
>
>	I guess I don't have to tell you how C handles the problem.
>In my opinion, it is by far, the most logical.

The for construct I know about which is by far the most logical
(though is also the hardest to implement efficiently) is the one
provided by CLU.

In short, CLU has this construct called an "iterator", which is
similar to a procedure, but instead of returning a single set of
values, "yields" a sequence of sets of values.  Each set is are
assigned in turn to the loop variables of a for statement and the body
of the for statement is executed.

-----
BTW: In C, one of my favorite standard macros is:

#define _forlist(var,init,next) for((var)=(init);var;(var)=(var)->next)

-- 
John G. Myers				John.Myers@k.gp.cs.cmu.edu

klaiber@udel.EDU (Alexander Klaiber) (03/12/88)

In article <1103@PT.CS.CMU.EDU> jgm@K.GP.CS.CMU.EDU (John Myers) writes:
>In article <1301@eneevax.UUCP> noise@eneevax.umd.edu.UUCP (Johnson Noise) writes:
>>In article <1345@daimi.UUCP> erja@daimi.UUCP (Erik Jacobsen) writes:
>>	I guess I don't have to tell you how C handles the problem.
>>In my opinion, it is by far, the most logical.
>
>The for construct I know about which is by far the most logical
>(though is also the hardest to implement efficiently) is the one
>provided by CLU.
>
>In short, CLU has this construct called an "iterator", which is
>similar to a procedure, but instead of returning a single set of
>values, "yields" a sequence of sets of values.  Each set is are
>assigned in turn to the loop variables of a for statement and the body
>of the for statement is executed.

Aaaaah... finally someone who promotes abstraction and information-hiding!
That's the spirit: Let the compiler do the dirty work, and who cares about 
a few cycles wasted when the program is so readable that maintenance costs
go down. Maybe one might even spend the time gained that way on implementing
a more efficient algorithm...

**warning: flame ahead
   Long live very-high-level languages, demote C to the rank of the mythical
   "universal assembler"
**end of flame  --  C fans, please relax

Alexander Klaiber
klaiber@dewey.udel.edu

sommar@enea.se (Erland Sommarskog) (03/16/88)

Wayne A. Christopher (faustus@ic.Berkeley.EDU) writes:
>In article <2827@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
>> ... Ada as I see it have
>> the perfect solution: The loop variable is declared in the FOR-
>> statement, and is thus not accessible afterwards.
>
>Here's the problem with that construct:  I often write
>	for (i = 0; i < max; i++)
>		if (something)
>			break;
>	if (i == max)
>          ...
>If the loop variable is inaccessible outside of the loop there's
>no way to tell how it terminated, except by using an extra flag,
>which is ugly.

Sorry to be a little rude, but is just an argument for the Ada style.
I find your style ugly and Ada stops you using it. Why is it ugly?
Because you're using i in two ways here. First as an iterator, and the 
as a flag to se if "something" (dit not) occur. So the extra flag is not
ugly. Another point is that I would probably use a WHILE loop instead.

Some proposals: (in Ada)
-- WHILE a la Pascal
i := 0;
While i < max and not something loop
...
End loop;
-- Here you *can* test use i for the test, but I'd prefer "something"

-- FOR loop with exit-statement. 
For i in 0..max - 1 loop   -- And why not 1..max? But we have had that debate.
   Exit when something;
End loop;
If not something then    

-- Or if "something" is an error condition, use an exception handler
Begin
   For i in 0..max - 1 loop
   End loop
   Do_the_normal_stuff;
Exception
   when Something => Clean_up_or_re_raise;
End;
Continue_if_you_like;



-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP           "Si tu crois l'amour tabou...
                            Regarde bien, les yeux d'un fou!!!" -- Ange

lee@ssc-vax.UUCP (Lee Carver) (03/18/88)

<>

Hope I didn't change the meaning of the parties prior discussion,
but in the following problem, why not package the loop as a
procedure/subroutine/function.  Clearly, it is being used to perform
an atomic action anyway.

Wayne A. Christopher (faustus@ic.Berkeley.EDU) writes:
>In article <2827@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
>> ... Ada as I see it have
>> the perfect solution: The loop variable is declared in the FOR-
>> statement, and is thus not accessible afterwards.
>
>Here's the problem with that construct:  I often write
>	for (i = 0; i < max; i++)
>		if (something)
>			break;
>	if (i == max)
>          ...
> >If the loop variable is inaccessible outside of the loop there's
> >no way to tell how it terminated, except by using an extra flag,
> >which is ugly.

Here's the way I do it by better packaging:

int findSomething ( max )
int max;
{  int i;

   for (i = 0; i < max; i++)
      if (something) return i;

   /* not found */
   return max;
   }

No extra flag, some call overhead, and a re-usable commponent.  What
could be better (besides no call overhead :-)?

On a similar vein, one occasionally sees calls for new control
structures to supports some really baroque nesting of if statements.
What every happened to packaging the embedded if conditions as
subroutines?

esh@otter.hple.hp.com (Sean Hayes) (04/14/88)

In article <YWK3hUy00VA88IO0UA@andrew.cmu.edu> jk3k+@andrew.cmu.edu (Joe Keane) writes:
>While i'm at childish flaming, i might as well say that i _really_ hate `fi',
>`rof', `esac', and `elihw'.  Can anyone say they're a good idea and keep a
>straight face?

Me too.  "They're a good idea."  :-|

Ok, maybe they're not that good, but at least they are obvious. I liked the Algol 68 notion
of allowing parentheses as an alternative when it made things clearer.

The closing of blocks of code with a delimiter is a must. The only viable alternative is 
Landins "offside rule", which forces the correct indentation. I don't know if this has been
tried in an imperative language.

Sean,


 _________________________________________________________________________
 |Sean Hayes,          Hewlett Packard Laboratories,      Bristol,  England|
 |net: esh@hplb.uucp   esh%shayes@hplabs.HP.COM       ..!mcvax!ukc!hplb!esh|

pase@ogcvax.UUCP (Douglas M. Pase) (04/17/88)

In article <otter.2400014> esh@otter.hple.hp.com (Sean Hayes) writes:
 The closing of blocks of code with a delimiter is a must. The only viable
 alternative is Landins "offside rule", which forces the correct indentation.
 I don't know if this has been tried in an imperative language.

Try Occam -- and that isn't one of its more pleasant features.
-- 
Doug Pase  --  ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu (CSNet)