<story><title>Guy Steele Interviews John McCarthy, Father of Lisp (2009)</title><url>http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy</url></story><parent_chain><item><author>ScottBurson</author><text>I should write a nice long blog post on how to iterate in CL without using (full) LOOP.  (I have no problem with the trivial CLtL1 form of LOOP.)  There&amp;#x27;s DO, there&amp;#x27;s MAPCAR, there&amp;#x27;s REDUCE, there&amp;#x27;s REMOVE-IF-NOT and the like, and these days we often have the option of using tail recursion.  I believe that different kinds of loops &lt;i&gt;should&lt;/i&gt; be written with different constructs, as this gives the reader a clue up front about the nature of the loop.  If you see a MAPCAR, for example, you can assume (well, you &lt;i&gt;should&lt;/i&gt; be able to assume) that the iterations are independent; there is no data flow from one invocation of the mapped function to another, so the ordering of the input list(s) affects only the ordering of the result list, not its contents.  Furthermore, any loop with that property &lt;i&gt;should&lt;/i&gt; be written as a MAPCAR so the reader can tell that.&lt;p&gt;The point, of course, is that trying to create &amp;quot;one macro to rule them all&amp;quot; &lt;i&gt;is already wrongheaded&lt;/i&gt;.  There &lt;i&gt;shouldn&amp;#x27;t be&lt;/i&gt; one universal iteration construct.</text></item><item><author>hga</author><text>When I was part of the social community that included most of the Lisp Machine hackers including several superb macrologists, call it 1980-3, I don&amp;#x27;t remember any other single thing generating more discussion.  Not about it being bad, or dangerously over-complicated, just what it should do and how.&lt;p&gt;So, yeah.  I don&amp;#x27;t remember using it more than once in my own code.</text></item><item><author>michaelcampbell</author><text>I don&amp;#x27;t know it enough to love or hate it, but I&amp;#x27;m reading one of Paul Graham&amp;#x27;s books where he says (paraphrasing) &amp;quot;Don&amp;#x27;t worry if you don&amp;#x27;t understand LOOP; no one understands LOOP.&amp;quot;</text></item><item><author>ScottBurson</author><text>&lt;i&gt;People have added some Englishy stuff and at least the syntax of that is not in the spirit of Lisp.&lt;/i&gt;&lt;p&gt;Ha!  I knew it!  He hated LOOP as much as I do!  :-)</text></item></parent_chain><comment><author>sjolsen</author><text>&amp;gt;The point, of course, is that trying to create &amp;quot;one macro to rule them all&amp;quot; is already wrongheaded. There shouldn&amp;#x27;t be one universal iteration construct.&lt;p&gt;I agree that MAPCAR et al. should be used &lt;i&gt;when they&amp;#x27;re appropriate&lt;/i&gt;. They are, however, sometimes simply not, and it&amp;#x27;s important to be able to build code to handle those cases. You don&amp;#x27;t &lt;i&gt;need&lt;/i&gt; LOOP for that, since you can always use TAGBODYs and GOs, but LOOP is almost certainly more appropriate, just as MAPCAR et al. are &lt;i&gt;usually&lt;/i&gt; more appropriate than LOOP.&lt;p&gt;In other words, yes, there should be a universal iteration construct; there just shouldn&amp;#x27;t be &lt;i&gt;only&lt;/i&gt; a universal iteration construct. There&amp;#x27;s nothing wrong with having multiple tools at different abstraction levels for the same group of tasks, and I&amp;#x27;d argue that it&amp;#x27;s usually a &lt;i&gt;good&lt;/i&gt; thing.</text></comment>
<story><title>Guy Steele Interviews John McCarthy, Father of Lisp (2009)</title><url>http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy</url></story><parent_chain><item><author>ScottBurson</author><text>I should write a nice long blog post on how to iterate in CL without using (full) LOOP.  (I have no problem with the trivial CLtL1 form of LOOP.)  There&amp;#x27;s DO, there&amp;#x27;s MAPCAR, there&amp;#x27;s REDUCE, there&amp;#x27;s REMOVE-IF-NOT and the like, and these days we often have the option of using tail recursion.  I believe that different kinds of loops &lt;i&gt;should&lt;/i&gt; be written with different constructs, as this gives the reader a clue up front about the nature of the loop.  If you see a MAPCAR, for example, you can assume (well, you &lt;i&gt;should&lt;/i&gt; be able to assume) that the iterations are independent; there is no data flow from one invocation of the mapped function to another, so the ordering of the input list(s) affects only the ordering of the result list, not its contents.  Furthermore, any loop with that property &lt;i&gt;should&lt;/i&gt; be written as a MAPCAR so the reader can tell that.&lt;p&gt;The point, of course, is that trying to create &amp;quot;one macro to rule them all&amp;quot; &lt;i&gt;is already wrongheaded&lt;/i&gt;.  There &lt;i&gt;shouldn&amp;#x27;t be&lt;/i&gt; one universal iteration construct.</text></item><item><author>hga</author><text>When I was part of the social community that included most of the Lisp Machine hackers including several superb macrologists, call it 1980-3, I don&amp;#x27;t remember any other single thing generating more discussion.  Not about it being bad, or dangerously over-complicated, just what it should do and how.&lt;p&gt;So, yeah.  I don&amp;#x27;t remember using it more than once in my own code.</text></item><item><author>michaelcampbell</author><text>I don&amp;#x27;t know it enough to love or hate it, but I&amp;#x27;m reading one of Paul Graham&amp;#x27;s books where he says (paraphrasing) &amp;quot;Don&amp;#x27;t worry if you don&amp;#x27;t understand LOOP; no one understands LOOP.&amp;quot;</text></item><item><author>ScottBurson</author><text>&lt;i&gt;People have added some Englishy stuff and at least the syntax of that is not in the spirit of Lisp.&lt;/i&gt;&lt;p&gt;Ha!  I knew it!  He hated LOOP as much as I do!  :-)</text></item></parent_chain><comment><author>malisper</author><text>I agree with you to some degree. Higher order functions should be used wherever possible and there should be some alternatives to LOOP for the common cases such as iterating over a range of numbers. It is much easier to understand patterns when they are built into the language than when they are written out using LOOP.&lt;p&gt;The thing is LOOP is very good at creating ad hoc kinds of loops. Say you are writing a loop to do password validation. Repeat at most N times and then lock the account or go through once a correct password is entered. That kind of iteration is too specific for pretty much any kind of looping construct besides LOOP.&lt;p&gt;As I see it, LOOP is not about creating &amp;quot;one macro to rule them all&amp;quot;, it&amp;#x27;s about creating a macro that&amp;#x27;s a catch-all. One that you can always use when nothing else quite describes what you want.&lt;p&gt;I&amp;#x27;m just thinking out loud.</text></comment>