Hey all.

Currently, most of the Lisp code that I write is under Emacs,
which has a limited recursion depth so I can't use functional
programming techniques :(.  So, now I'm working on some code
and I find that the most convenient way to continue is to modify
the parameters to a function that I'm writing.

I checked out some tutorials but didn't find much.  The only
thing I found was the set function, and doing the following
under Emacs seemed to work (this isn't the function I'm writing
BTW :)):

(defun fn (x)
  (set x some-value))

(setq p 100)
(fn 'p)  ;; This changes the value of p

Now, I'm just wondering is this the proper way of doing things?
Is there a better way of doing it?  The thought of manipulating
symbols like that has some warning bells ringing in the back
of my head, but I could use some advice from those more experienced
than I.

Thanks.

--
Cya,
Ahmed

In article <5doasq$...@Masala.CC.UH.EDU> cosc1...@Bayou.UH.EDU

--

William Paul Vrotney (vrot...@netcom.com) wrote:

: In article <5doasq$...@Masala.CC.UH.EDU> cosc1...@Bayou.UH.EDU

: No problem, this is proper.  'set' is very useful for writing programs that
: interpret Lisp code which may be what you are doing.  For example, you
: mentioned Emacs, the function M-x set-variable would need to use 'set' to
: set a variable name that you give it.  Your head ringing was due to the fact
: that rarely do Lisp programmers have to use either 'set' or 'eval' but
: sometimes it is either necessary or more straightforward.

*Nod*.  Normally I wouldn't use set, setq, setf, or any looping
constructs, but rather a functional style of programming, but
since Emacs has a rather limited recursion depth, I find that I'm
forced to use imperative programming techniques.  Nontheless even
using that paradigm Lisp shines.

Thanks a ton for the info.  I'm really happy that I gave Lisp a
second try.  It's great having a language which is both flexible
and has a nice juicy library of functions.  Very often it seems
that you only get one or the other.

Thanks again.

: --

: William P. Vrotney - vrot...@netcom.com

--
Cya,
Ahmed

   From: cosc1...@Bayou.UH.EDU (cosc1...@bayou.uh.edu)
   Date: 11 Feb 1997 03:39:29 GMT

   William Paul Vrotney (vrot...@netcom.com) wrote:

   : (cosc1...@bayou.uh.edu) writes:
   : No problem, this is proper.  'set' is very useful for writing programs that
   : interpret Lisp code which may be what you are doing.  For example, you
   : mentioned Emacs, the function M-x set-variable would need to use 'set' to
   : set a variable name that you give it.  Your head ringing was due to the fact
   : that rarely do Lisp programmers have to use either 'set' or 'eval' but
   : sometimes it is either necessary or more straightforward.

   *Nod*.  Normally I wouldn't use set, setq, setf, or any looping
   constructs, but rather a functional style of programming, but
   since Emacs has a rather limited recursion depth, I find that I'm
   forced to use imperative programming techniques.  Nontheless even
   using that paradigm Lisp shines.

   Thanks a ton for the info.  I'm really happy that I gave Lisp a
   second try.  It's great having a language which is both flexible
   and has a nice juicy library of functions.  Very often it seems
   that you only get one or the other.

The elided code:

 2.5 reasons.

   From: cosc1...@Bayou.UH.EDU (cosc1...@bayou.uh.edu)
   Date: 11 Feb 1997 03:39:29 GMT

   William Paul Vrotney (vrot...@netcom.com) wrote:

   : (cosc1...@bayou.uh.edu) writes:
   : No problem, this is proper.  'set' is very useful for writing programs that
   : interpret Lisp code which may be what you are doing.  For example, you
   : mentioned Emacs, the function M-x set-variable would need to use 'set' to
   : set a variable name that you give it.  Your head ringing was due to the fact
   : that rarely do Lisp programmers have to use either 'set' or 'eval' but
   : sometimes it is either necessary or more straightforward.

   *Nod*.  Normally I wouldn't use set, setq, setf, or any looping
   constructs, but rather a functional style of programming, but
   since Emacs has a rather limited recursion depth, I find that I'm
   forced to use imperative programming techniques.  Nontheless even
   using that paradigm Lisp shines.

   Thanks a ton for the info.  I'm really happy that I gave Lisp a
   second try.  It's great having a language which is both flexible
   and has a nice juicy library of functions.  Very often it seems
   that you only get one or the other.

[I wrote the following before I realized you weren't necessarily
defining p at top-level.  Here it is anyway, for what it's worth...]

The elided code:

 2.5 reasons.

Carl L. Gay (c...@politix.cs.uoregon.edu) wrote:

[Snip]

: [I wrote the following before I realized you weren't necessarily
: defining p at top-level.  Here it is anyway, for what it's worth...]

: The elided code:
: > (defun fn (x)
: >   (set x some-value))
: >
: > (setq p 100)
: > (fn 'p)  ;; This changes the value of p

: Um, this may be proper in some sense but it sure sets bells ringing in
: my head too.  I can think of at least two reasons why I wouldn't use
: this method:
:   - It pollutes the top-level namespace with what should really be
:     local variables.  Someone's liable to mess with them.
:   - Using SET will make the reader think something more complicated is
:     going on and there's a good reason for using it.  There isn't, and
:     there isn't.

Also trying to pass it on to another function is pure agony.
For instance I tried the following:

(defun f (x)
  (g x))

(defun g (x)
  (set x 10))

(setq n 100)
(f 'n)

The quoting scheme collapsed when I hit g since I was passing
a variable.  I realized that I had to find a far better way.

:   - There's a simple, relatively clean workaround:
:     (defun fn (x)
:       (setcar x some-value))
:     (fn (list 100))
      ^^^^^^^^^^^^^^^

Shouldn't the above be (fn (list some-var)) where some-var has
been previously defined?  We are trying to modify the argument
so passing a literal won't do.

I did make the appropriate substitution, but it didn't work.

:     Or, if you do this a lot, define a CONTAINER abstract data type so
:     you can among other things distinguish your container from another
:     list.

Wouldn't there be an easier way?  I mean setq modifies its parameters
and that's all I'm trying to do.  Ie:

(f x)  ;; I want x to change like it would in (setq x 100)

:  2.5 reasons.

:)

Thanks for the help.

: -Carl

--
Cya,
Ahmed

   From: cosc1...@Bayou.UH.EDU (cosc1...@bayou.uh.edu)
   Date: 12 Feb 1997 01:34:14 GMT

   Also trying to pass it on to another function is pure agony.
   For instance I tried the following:

   (defun f (x)
     (g x))

   (defun g (x)
     (set x 10))

   (setq n 100)
   (f 'n)

   The quoting scheme collapsed when I hit g since I was passing
   a variable.  I realized that I had to find a far better way.

I'm not sure I understand what you mean.  The above seems to work
fine.  You're passing the symbol N, not a variable.

   :   - There's a simple, relatively clean workaround:
   :     (defun fn (x)
   :       (setcar x some-value))
   :     (fn (list 100))
         ^^^^^^^^^^^^^^^

   Shouldn't the above be (fn (list some-var)) where some-var has
   been previously defined?  We are trying to modify the argument
   so passing a literal won't do.

Well that was just for illustration.  Presumably you'd want to look at
the value after calling fn:

(let ((foo (list my-var)))
  (fn foo)
  (do-something (car foo)))

   :     Or, if you do this a lot, define a CONTAINER abstract data type so
   :     you can among other things distinguish your container from another
   :     list.

   Wouldn't there be an easier way?  I mean setq modifies its parameters
   and that's all I'm trying to do.  Ie:

   (f x)  ;; I want x to change like it would in (setq x 100)

Carl L. Gay (c...@plastix.cs.uoregon.edu) wrote:

:    From: cosc1...@Bayou.UH.EDU (cosc1...@bayou.uh.edu)
:    Date: 12 Feb 1997 01:34:14 GMT

[Snip]

:    The quoting scheme collapsed when I hit g since I was passing
:    a variable.  I realized that I had to find a far better way.

: I'm not sure I understand what you mean.  The above seems to work
: fine.  You're passing the symbol N, not a variable.

Well it's a moot point now since I found something that can
do the trick -- macros.  How I forgot about them I can
only speculate.  Thanks for the assistance.

[Snip]

:    Wouldn't there be an easier way?  I mean setq modifies its parameters
:    and that's all I'm trying to do.  Ie:

:    (f x)  ;; I want x to change like it would in (setq x 100)

: You could try setting max-lisp-eval-depth higher.

I did that (to enable some appreciable amount of recursion).
I believe the maximum is around 600, which while not bad
isn't enough to make me use it in scenarios where I don't
know how many recursions I'll get into (it would be nice
if Emacs also did some tail recursion optimization).

Thanks again for the help.

--
Cya,
Ahmed

* Carl L. Gay
| You could try setting max-lisp-eval-depth higher.

* cosc1...@Bayou.UH.EDU
| I did that (to enable some appreciable amount of recursion).  I believe
| the maximum is around 600, which while not bad isn't enough to make me
| use it in scenarios where I don't know how many recursions I'll get into
| (it would be nice if Emacs also did some tail recursion optimization).

I'm getting a bit annoyed by these continued references to deficiencies in
Emacs that are really just deficiencies in your ability or willingness to
read the Emacs Lisp manual.  I have already answered the implied question
"can I make Emacs more friendly towards recursion, and if so how" in your
incessant and incorrect complaints that "Emacs doesn't allow recursion"
with references to `max-lisp-eval-depth' and `max-specpdl-size', but lots
of people out there will still believe your misguided complaints.  _please_
be more willing to ask for help and less willing to complain.

you "believe" there is a small maximum.  I _know_ there isn't.  you hit the
600 limit because that's what `max-specpdl-size' is set to and you probably
had one let-binding in your recursive function.  increase the value of this
variable to some obscenely large value and watch Emacs hit some hard limit
and die, instead.  again, it is more friendly of Emacs to complain than to
crash, and it crashes because being able to respond when you're out of
stack space may not be very expensive, but handling the situation cleanly
usually is.  to illustrate this point: watch what various Lisps do when
they exhaust their memory -- clean recovery is not usually an option.
Emacs has taken great pains to survive a "memory outage" when the user
creates too many or too large buffers, by allocating a "memory reserve"
that it uses when it suggests that you save all buffers and kill and
restart Emacs.  something similar is not undoable with stack space, but is
much harder to make work right.  unlimited recursion depth also allocates
system stack space that is not typically returned to the operating system
when the stack unwinds.  this is a frequent cause of the very large Lisp
images that people complain about.

: * cosc1...@Bayou.UH.EDU
: | I did that (to enable some appreciable amount of recursion).  I believe
: | the maximum is around 600, which while not bad isn't enough to make me
: | use it in scenarios where I don't know how many recursions I'll get into
: | (it would be nice if Emacs also did some tail recursion optimization).

: I'm getting a bit annoyed by these continued references to deficiencies in
: Emacs that are really just deficiencies in your ability or willingness to
: read the Emacs Lisp manual.  

Or deficiencies in the way the manual is written.  Oh but to suggest
this would mean that you'd lose your chance to bash me and I wouldn't
dream of doing that to you.

BTW, before you go on with your rant, I'd just like you to know that
not only do I not have anything against Emacs, but it is my favorite
program of *ANY TYPE*.  I had a reputation of being an Emacs junkie
simply because I would stop people I recognized in the halls, convinced
that they should know the joy of Emacs whether or not they liked it,
so kindly refrain from your implications.

Now on to the rest of your post.

: I have already answered the implied question
: "can I make Emacs more friendly towards recursion, and if so how" in your
: incessant and incorrect complaints that "Emacs doesn't allow recursion"
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Either your memory is fuzzy or your reading skills are lacking and I
frankly don't care which one it is, I never said "Emacs doesn't allow
recursion", (I'm letting you get away with the previous quote simply
because it's an accurate summary).  Either get my quotes right or
save the bandwidth.

: with references to `max-lisp-eval-depth' and `max-specpdl-size', but lots
: of people out there will still believe your misguided complaints.  _please_
: be more willing to ask for help and less willing to complain.

I asked a question, and when it seemed I was wrong I made sure to
make statements like "I was under the impression...".  I did not
complain and I even emphasized at the end of my posts that I still
adored Emacs and even if my questions made it seem otherwise, it
was one helluva tool.  I even referred to it as a "goldmine".

Why don't you stop shooting off your mouth and actually spend time
*READING* an entire post before you spout drivel here.  My posts
are in this thread, read them thoroughly and you'll see that --
well let's not mince words -- that you are full of shit my dear
Erik.

: you "believe" there is a small maximum.  I _know_ there isn't.  

Exactly.  I stated that I was under the impression that certain
things held.  

: you hit the
: 600 limit because that's what `max-specpdl-size' is set to and you probably
: had one let-binding in your recursive function.  

I knew about the max-specdpl-size setting but the let-binding is new
to me.  I did not see any mention of it in the info that I read in
Emacs and therefore did not know how it applied.

: increase the value of this
: variable to some obscenely large value and watch Emacs hit some hard limit
: and die, instead.  

Yes I was fortunate enough to witness this first hand.  I set the
value of max-specdpl-size as per your last post (unlike you I
actually read a post before rambling) to a substantial number.
I believe it was 100,000.  I was definitely more capable of
deeper recursion levels then but due to some sequence of events
(long nasty story about debugging and setting the values frequent
times) my system died an agonizing death.  This was on a SparcStation 2
running Solaris with Emacs 18.X in it running under X-Windows.
Not that I'm holding Emacs to blame (heaven knows you've got enough
BS to throw already without my providing anymore), it was probably
due to some funny stuff I did, but the recursion level did
improve noticeably, enough so that I am now going to utilize
functional programming techniques under Elisp.

: again, it is more friendly of Emacs to complain than to
: crash, and it crashes because being able to respond when you're out of
: stack space may not be very expensive, but handling the situation cleanly
: usually is.  

Yes I know, but why doesn't it eliminate tail recursion rather than
forcing any kind of nesting limit?

: to illustrate this point: watch what various Lisps do when
: they exhaust their memory -- clean recovery is not usually an option.
: Emacs has taken great pains to survive a "memory outage" when the user
: creates too many or too large buffers, by allocating a "memory reserve"
: that it uses when it suggests that you save all buffers and kill and
: restart Emacs.  something similar is not undoable with stack space, but is
: much harder to make work right.  unlimited recursion depth also allocates
: system stack space that is not typically returned to the operating system
: when the stack unwinds.  this is a frequent cause of the very large Lisp
: images that people complain about.

I am well aware that Emacs is quite robust and what it does it does
for a good reason -- I never stated otherwise.  I merely had some
questions that you seem to have taken offense at (and you'll probably
take further offense at this post).

Have a nice day Erik and I certainly hope you manage to dislodge
from your posterior whatever it is that is making you so belligerent.

: #\Erik
: --
: my other car is a cdr

--
Cya,
Ahmed

* cosc1...@Bayou.UH.EDU
| Have a nice day Erik and I certainly hope you manage to dislodge
| from your posterior whatever it is that is making you so belligerent.

whatever your feelings may have been at that final point of your article,
your escalating hostilites are uncalled-for.  I found your article
predominantly destructive and I have no use for your destructivism.  your
repeated complaints about the limitations of recursion in Emacs does not
mesh with someone who reads manuals, which I infer from your hostile
ranting that I have insulted you gravely by implying.  I _would_ have had a
use for suggestions to improve the manual if you found it so lacking, but
you don't even give any reason for that.  there's nothing I can do to help
your situation.  I honestly thought you needed to know about those
variables since you sounded to frustrated, but you also sound a lot more
frustrated than somebody who wants to have a problem solved would do, and
so I tried to explain just why they are set so low as to limit your
experiments with recursion to the point where you feel the need to post
your negative experiences, beliefs, assumptions, whatever, but not nearly
enough to read the manual to find better ways experiment with recursion.

if you actually have something constructive to suggest for GNU Emacs 19.35,
code or manuals, let me know.  I'll make sure it makes it into the release
if it is sound advice, i.e., quite unlike the above quoted sentence.  it's
your call, since you have the problems.  I couldn't care less what you run
into if you don't read the manual, but I do care that users out there might
actually believe there are limitations that can't be relaxed.  OK?

: whatever your feelings may have been at that final point of your article,
: your escalating hostilites are uncalled-for.  

My hostilities were directly in response to your smug attitude
and deliberate misrepresentation.  You made no attempt to
read my post and then proceeded to deliberately toss around
BS and pin it on me.  If you want to know just why I feel
contempt towards you, read the article to which you were
originally responded (this time read it all the way through)
then read your arrogant response.  You will see that my actions
were well justified.

: I found your article
: predominantly destructive and I have no use for your destructivism.  

I've seen your handiwork on other threads.  While I have no doubt
that you are a knowledgable person, you are also belligerent,
arrogant, cocky, smug, abusive and rude.  The thread "Superior
Programming Languages" comes to mind, particularly some of
the responses you posted based on the Lisp benchmark.

: your
: repeated complaints about the limitations of recursion in Emacs does not
: mesh with someone who reads manuals, which I infer from your hostile
: ranting that I have insulted you gravely by implying.  

Well then you obviously need to work on your logic now don't you?
The first thing I do whenever there's a problem is to read the
manuals.  I invoke "describe function" and/or "describe variable/key"
as appropriate and try to search for some likely names and do
some homework from there.  Then if need be I pull up the info
pages and start hopping down links and running searches in an
attempt to find what I need. It is only as a last resort that
I ask for help publicly.

From what I read I found that there was a max-lisp-eval-depth
variable as well as a max-sepdcl-? variable.  The max-lisp-eval-depth
was described and I knew I could set it, but the max-sepdcl-? was
described as some kind of limit, so naturally I assumed that it
would not behoove me to set it.  The organization of the variables
and wording of the document led me to believe this.

While this is in fact a misunderstanding on my part, it did not
warrant the sort of crass attitude you were dealing out in your
previous post.

: I _would_ have had a
: use for suggestions to improve the manual if you found it so lacking, but
: you don't even give any reason for that.  

First and foremost, I did not have suggestions for improving anything
simply because at the time I was not sure as to what was going on.
It was only after you mentioned setting the max-sepdcl-? variable
that it occurred to me that the manual (or at least organization
of these variables with max-sepdcl-? seeming to be some sort
of constant) could use some work.  Of course I couldn't make this
suggestion because when I came back, I was busy warding off the
flames you sent my way.

: there's nothing I can do to help
: your situation.  I honestly thought you needed to know about those
: variables since you sounded to frustrated, but you also sound a lot more
: frustrated than somebody who wants to have a problem solved would do, and
: so I tried to explain just why they are set so low as to limit your
: experiments with recursion to the point where you feel the need to post
: your negative experiences, beliefs, assumptions, whatever, but not nearly
: enough to read the manual to find better ways experiment with recursion.

Again you demonstrate your deliberate lies about the contents of my
previous post.  Erik, don't expect to innaccurately summarize my
post like that without a heated response from me.  I may need
help, but I don't need help so badly that I'd put up with your
sh*t.  Understand?

: if you actually have something constructive to suggest for GNU Emacs 19.35,
: code or manuals, let me know.  

If I have something constructive to suggest for GNU Emacs 19.35 I'll
find someone more worthwhile to tell it to.  You Erik are a person
I'd much rather avoid.

: I'll make sure it makes it into the release
: if it is sound advice, i.e., quite unlike the above quoted sentence.  it's
: your call, since you have the problems.  I couldn't care less what you run
: into if you don't read the manual, but I do care that users out there might
: actually believe there are limitations that can't be relaxed.  OK?

Erik you truly are a fool.  Read my original posting thoroughly before
shooting off here.  You are whining about me giving readers false
impressions while in all reality your deliberate misrepresentation
is doing precisely that.  Pot.  Kettle.  Black.

At least now I know what was lodged in your posterior -- your head.

: #\Erik
: --
: my other car is a cdr

* cosc1...@Bayou.UH.EDU
| [ more hostile crap]

the "manual" is the Emacs Lisp Reference Manual, not the documentation
strings.  it appears that you don't even _know_ of the former, yet become
extremely hostile when I suggest that you would have found the answers you
needed there.  FYI, here are the relevant parts of it:

in the node (elisp)Eval:

 - Variable: max-lisp-eval-depth
     This variable defines the maximum depth allowed in calls to `eval',
     `apply', and `funcall' before an error is signaled (with error
     message `"Lisp nesting exceeds max-lisp-eval-depth"').  This counts
     internal uses of those functions, such as for calling the functions
     mentioned in Lisp expressions, and recursive evaluation of
     function call arguments and function body forms.

     This limit, with the associated error when it is exceeded, is one
     way that Lisp avoids infinite recursion on an ill-defined function.

     The default value of this variable is 200.  If you set it to a
     value less than 100, Lisp will reset it to 100 if the given value
     is reached.

     `max-specpdl-size' provides another limit on nesting.  *Note Local
     Variables::.

in the node (elisp)Local Variables:

 - Variable: max-specpdl-size
     This variable defines the limit on the total number of local
     variable bindings and `unwind-protect' cleanups (*note Nonlocal
     Exits::.) that are allowed before signaling an error (with data
     `"Variable binding depth exceeds max-specpdl-size"').

     This limit, with the associated error when it is exceeded, is one
     way that Lisp avoids infinite recursion on an ill-defined function.

     The default value is 600.

     `max-lisp-eval-depth' provides another limit on depth of nesting.
     *Note Eval::.

the sources for the Emacs Lisp Reference Manual is found at

    prep.ai.mit.edu:/pub/gnu/elisp-manual-19-2.4.2.tar.gz

and at any of the numerous mirrors.

: the "manual" is the Emacs Lisp Reference Manual, not the documentation
: strings.  it appears that you don't even _know_ of the former, yet become
: extremely hostile when I suggest that you would have found the answers you
: needed there.  FYI, here are the relevant parts of it:

Again you flaunt your illiteracy for the entire group to witness.
If you are through making a debacle of yourself I shall merely
tell you to re-read my previous post where I stated that I read
the documentation strings *AND* info nodes from within emacs.
I can pull a direct passage out of my text if you so desire.

: in the node (elisp)Eval:

[Snip]

Nice, and while definitely more sizeable than the documentation
strings they don't say anything more than what I already knew
from reading the doc strings.  

[Snip]

: #\Erik
: --
: my other car is a cdr

--
Cya,
Ahmed

In article <5doasq$...@Masala.CC.UH.EDU> cosc1...@Bayou.UH.EDU (cosc1...@bayou.uh.edu) writes:

* Chris Bitmead
| Are you saying Elisp isn't tail recursive?

Emacs Lisp does not do tail call merging (or tail recursion) optimization,
neither for self-recursive nor for non-self-recursive functions.  for
debugging purposes, I think it is necessary to be able to turn it off.

| Would anyone like to tell us why not?

I don't know why not, but since recursion is not a big deal in Emacs Lisp,
there probably was no reason to do it.

| It's not hard to implement surely?

well, you're welcome to do it, if you would like it.  I just looked around
a bit, and I think the easiest way to do it is to optimize the byte-code
interpreter to effectively do the cleanup processing normally associated
with a return from a function before the tail call.  normally, you don't
look ahead in the byte-code vector, but this would be a special case that
can be improved and expanded in increments.  the biggest problem is making
sure that the call stack is cleaned up correctly.  I'm not sure this would
be a problem in practice, but I have never hacked the byte-code interpreter.

Briefly, saving and restoring the variable bindings gets in the way.
It's possible to fix that, but a pain.

    (defun foo (x)
      (bar (+ x 1)))

    (defun bar (y)
      (+ x y))

    (foo 1)

This is legal in Elisp.  But since bar can refer to x, bound in foo,
you really need foo's stack frame still to exist inside bar, so the
binding can be looked up.  And even if bar doesn't use x free, some
function it calls may do, and foo has no way of knowing what such
functions may be.  So it's very hard to compile this as a jump, or if
you do compile it as a jump, you still have to keep all the old
bindings around to restore when you exit bar, so you just need a stack
of bindings somewhere even if not a call stack.

Does anyone know if it is possible to to general tail call elimination
(or even to do it in a useful set of cases) in a language with dynamic
scope?

In article <ey3ohdfjxap....@staffa.aiai.ed.ac.uk>,
Tim Bradshaw  <t...@aiai.ed.ac.uk> wrote:

* Chris Bitmead
| I think tail-call elimination within the same function scope would be
| quite sufficient.  Doesn't elisp support even this?

how many times do you need to be given the same answer before you realize
that if _you_ want it and it isn't implemented, _you_ can do it?

to reiterate the same answer you got last time: the Emacs Lisp compiler
does not do tail call merging.  period.

In article <BITMEADC.97Feb25094...@alcatel.com.au>,

If you're referring to optimizing away the indirection through the symbol's
function cell in directly recursive functions, that's completely
different.  And it results in incompatible changes to semantics to the
language.  In particular, consider how the "advise" macro works; it does
something like:

(setq *saved-function* (symbol-function 'name))
(setf (symbol-function 'name)
  '(lambda args ... (apply *saved-function* args) ...))