Subject: Re: Bad Idiom? From: Erik Naggum <erik@naggum.no> Date: 1997/01/08 Newsgroups: comp.lang.lisp Message-ID: <3061745622994770@naggum.no> * Will Hartung | I know that the function I presented works suspiciously like MAPCAR | (Thanx Rainer!), but I was trying to understand how the "helper function" | idiom translated from Scheme to Lisp. I have seen that idiom used much less in Common Lisp than in Scheme. I believe the main reason for this is that Scheme provides neither packages nor separate namespaces for functions and variables, so a helper function would pollute the only namespace you have if it was not lexically enclosed. however, the main reason I think helper functions are used in Scheme is that binding a function to a different symbol (name, really) tends to wreak havoc with explicit recursion. by "explicit recursion" I mean that a function calls itself by name. a lexically enclosed helper function allows a function to call a function which is known by name, even though the calling function may not know its _own_ name. Scheme-lovers argue that functions are "more first-class" in Scheme than in Common Lisp. I think this idiom is a consequence of that, namely that functions can end up being assigned to any varabiel and thus called any which way. | But would a Compiler make a more efficient construct using LOOP than a | similiar tail-recursive technique? I would imagine that something that is | (somewhat) intuitive in a recursive function may not translate to well to | the LOOP macro. depends on the compiler. I asked about a similar question some time ago (whether (map nil <function> <list>) and (dolist (elt <list>) (<function> elt)) would compile to the same code), and the answers I received uniformly supported my assumption that this should be possible, indeed common. | I guess the real question is whether the LOOP macro is worth studying, or | should I just skip it and rely on the other contructs and techniques that | I've learned from Scheme and the simpler functions available in Lisp? yes, the loop macro is worth studying. | It's difficult at this point because I feel like I'm walking on eggs. I | question everything I'm doing. Am I doing the right thing? Is this the | best way? CL is so big, I feel like I'm always missing something. | Perhaps I should just shut up, write my little projects and then find | some soul willing to kibitz the code after it works. I felt that way with C++ (which is why I took up Common Lisp for real). however, in C++, your program will crash or unexpectedly fail in more subtle ways if you don't include the right incantations. in Common Lisp, there is nothing that can have such adverserial effects, so you're always doing the right thing (insofar as you know what you're doing at all :), even if you don't do it the best way. this is the joy of learning I find with Common Lisp, namely that I _don't_ have to know the entire language before I can start doing something productive in it. the same goes for Franz, Inc's Allegro Common Lisp. I'm using both the Windows and the Unix versions and they have about 1200 pages of user manuals combined. I have fond it extremely instructive to read manuals from cover to cover, not the least because what makes a difference in Lisp systems is what is offered in addition to the Common Lisp compiler and interpreter. however, at no point did I feel that if I did something less than optimal, it would crash on me or lose my work. in my view, this is quite different a feeling from what one is taught to expect in the C/C++/Unix world. I don't know if Scheme is similarly pavlovian in its effects on programmers who make mistakes. | But working with CL is like walking into the local warehouse hardware | store looking for a hammer, and upon entering the tool section, not only | do I find a WALL of hammers, but walls of everything else as well. but in C++, they are all wired to the 110V mains outlet, so if you pick up the hammers in the wrong order, you get seriously fried. the Common Lisp hammers are all just hammers, no evil included. #\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.