> (defsubst cadr (x)
> "Return the car of the cdr of X."
> (car (cdr x)))
There has already been discussions of such issues on this list. There are
various ways to make byte-opt.el get rid of the extra varbind.
I had a suggestion, but it's not robust against some improperly nested
byte-code (
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> > When cadr is called interpretively, the binding of x is like
> > any other binding.
>
> Sure, but the binding can't possible have any effect on the
> result.
>
> In the particular case of cadr, it can't, because no non-primitive
> When cadr is called interpretively, the binding of x is like any
> other binding.
Sure, but the binding can't possible have any effect on the result.
In the particular case of cadr, it can't, because no non-primitive
functions are called. If the compiler could detect this kind of c
The binding for x is completely unnecessary and wasteful.
It is necessary in order for compiled code to do the same thing
as the interpreted code. When cadr is called interpretively,
the binding of x is like any other binding.
Now, we could consider adopting the convention that it is ok for
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> The binding for x is completely unnecessary and wasteful.
>
> It is necessary in order for compiled code to do the same thing as
> the interpreted code.
No, unless by "same thing" you mean "equally inefficient" in which
case defsubst would n
Hi, we have
(defsubst cadr (x)
"Return the car of the cdr of X."
(car (cdr x)))
And if we use that, for example, in
(defun woozle (blurb) (cadr blurb))
then the byte compiler delivers the result:
byte code for woozle:
args: (blurb)
0 varrefblurb
1 dup
2 varb
