Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!udel!klaiber
From: klaiber@udel.EDU (Alexander Klaiber)
Newsgroups: comp.lang.misc
Subject: Re: For loops (was: Re: From Modula to Oberon)
Message-ID: <1495@louie.udel.EDU>
Date: 12 Mar 88 02:39:05 GMT
References: <7161@sol.ARPA> <2787@enea.se> <1345@daimi.UUCP> <1301@eneevax.UUCP> <1103@PT.CS.CMU.EDU>
Sender: usenet@udel.EDU
Reply-To: klaiber@udel.EDU (Alexander Klaiber)
Organization: University of Delaware
Lines: 29
Keywords: FOR loop

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