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.