LOn Fri, Jan 26, 2024, 07:32 Eli Zaretskii <
eliz@gnu.org> wrote:
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 25 Jan 2024 18:15:48 -0500
>
> I've been annoyed at the use of lists to represent function values for
> a while now. For a reason I cannot fathom, I even managed to reproduce
> that very same mistake in Emacs-24 with the `(closure ...)` value for
> statically scoped interpreted function values.
>
> That was a major blunder.
>
> In any case, I'm playing around with a "fix", making lambda evaluate
> (when interpreted) not to (lambda ...) or (closure ...) but to
> a self-evaluating value that can be more reliably distinguished.
Maybe I'm missing something, but I always thought that having code and
data indistinguishable is one of the strong sides of Lisp. Are we now
going to make this advantage smaller, by deprecating the use of lists
to represent functions?
The printed representation has this "homoiconic" property, yes. Not necessarily the internal representation resulting from code that is evaluated or compiled. And not desirably.
I _think_ Stefan is complaining that some objects in the lisp runtime that are funcallable also respond to consp, and that makes it hard to distinguish (for purposes of optimization & tooling, I suppose).
So basically:
(funcall (lambda ()))
Is fine and correct, but:
(funcall '(lambda ()))
Shouldn't be fine, yet it is.
I can't check right now, but I think I know of at least one other Lisp that allows this.
João