Re: Distinguishing `consp` and `functionp`

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Thu, Jan 25, 2024 at 18:15:48 -0500, Stefan Monnier wrote:
> I've been annoyed at the use of lists to represent function values for
> a while now.

Why?  Lists are the natural representation, and traditional in Lisp.
They bring all sorts of advantages (like being able to manipulate code
easily in Lisp).

> 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.

Blunder?  Having (closure ...) alongside (lambda ...) is an
inconvenience, yes, but ...  Why a "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.
> In the patch below, I just reused the #[...] byte-code objects for that,
> putting the function's body where the bytecode string goes and the
> function's captured environment where the "constant vector" goes.

Please don't do that.  If you must invent a new form, then invent a new
symbol to signify it.  Misusing #[...] will lead to problems and extra
work for everybody (as, for example, using the doc string field in
oclosures for something else has led to extra work).

> It's got several rough edges (most importantly that
> `byte-code-function-p` returns non-nil for interpreted function
> values), but it seems to work OK so far.

> You can't use the patch as-is because it's written against my local
> branch, with various local hacks, some of which (partly) remove support
> for lexical-binding==nil.
> But hopefully, it's readable enough for you to form an opinion.

> WDYT?

You haven't given any substantial motivation for such a change.  Being
"annoyed" at something is hardly grounds for making such far reaching
changes.  You haven't said what advantages the change would bring,
beyond saying that the proposed function form will be "more easily
distinguished".

Any packages out there that deal with the internal format of Lisp code
will be severely affected.  At the very least, they'll need amendment to
cope with the new format alongside the current format of code.

For example, my amendments for bug #67455 (Putting position information
into doc strings) are already difficult enough.  This change would add a
whole new layer of indirection into bug #67455's changes.

>         Stefan

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).