Subject: Re: Returning the name of a function
From: Erik Naggum <erik@naggum.no>
Date: 2000/01/18
Newsgroups: comp.lang.lisp
Message-ID: <3157214622741552@naggum.no>

* sashank@vuse.vanderbilt.edu (Sashank Varma)
| they can definitely differ if the magic-defuned function returns
| a closure, e.g.:

  this illustrates the incompleteness of the "solution".  take a hint and
  realize that when a "solution" causes more new problems than it solves,
  it's time to garbage collect it and look for what _solves_ the problem.

  all in all, this "what's my name" question about functions is entirely
  bogus, and we're just improving the way we get lost, instead of trying to
  find our way home.  see the manual on debugging if you use Allegro CL.
  I'm sure the other professional Common Lisps have similar debugging
  capabilities.  (the free Lisps are lacking in this department to an
  extent that those who reject commercial software will never understand
  until they overcome their rejection.)

  the way we deal with "what's my name" in recursive functions is to use
  FLET inside the function, call it with suitable arguments, and avoid the
  entire overhead of calling through a symbol's function slot.  this also
  works well with anonymous functions.  however, it's a lexical name, and
  there's no guarantee that no other function will do the same, so there's
  no point in externalizing the name -- in fact, the opposite is the point:
  to avoid externalizing the name.
  
  Allegro CL comes with sufficient documentation and source code for
  regular licencees that you can easily figure out how to get the function
  object of the current frame.  in most cases, you can query the function
  object for the symbol (actually, function name) to which it was bound at
  some time in the past.  you have no guarantee that you get back the same
  function object if you ask for the FDEFINITION of that function name.

  it seems I'm repeating myself, but you are debugging up the wrong tree.
  learn to use the Common Lisp debugger, don't try to emulate the behavior
  you have been forced to accept from some inferior language -- it will
  make Common Lisp seem inferior because we don't solve problems that never
  should have had a solution in the first place, and the cost of which
  solution actually carries severe penalties on the language design.

#:Erik