Re: Always-true predicate?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>   Also, I'm not completely sure in which sense it "miscompiles" it,
>>   since it can't be compiled correctly, AFAIK.  ]
>
> ???
>
> It's perfectly valid ELisp. It should throw. It doesn't.

You're right, technically.  But most of the time that code like that
shows up, it's just a bug and the intended semantics is different.
IOW I'd be surprised if there is a piece of code out there that wants
this to signal an error ;-)

[ But, just to clarify: I'm not trying to defend this as "not a bug".
  It *is* a bug in the optimizer, no more, no less.  ]

> So to avoid having to cons up a new list you have to know about the
> callee to know it doesn't do that, which apply prevents you from
> doing.

I don't see what you mean by "apply prevents you from doing".  But in
any case, I'd happy to change my stance to say that the guilt is shared
between `apply` and `&rest`.

And yet another way to look at it is that the real culprit is the fact
that `cons` cells are mutable ;-)

> Looking forward to your patch removing all argument names from defuns
> everywhere ;-)

It's almost ready.

> It seems obvious to me that if f and g are "the same",

Function equality and "obvious" just don't belong in the same sentence, IMO.

> BTW, I made a mistake in my previous email:
>
> (f a &rest b c) should be equivalent to (apply #'f a (append b (list
> c))). No zips, and no spreadification of the last argument.

That reminds me of the macro `gnus--,@` I introduced recently (it's
not the same, since ,@ would splice at macro-expansion time, whereas
your &rest here wants to splice at run time).


        Stefan