[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Unify make-closure, make-interpreted-closure, and make-byte-code
From: |
Thuna |
Subject: |
Unify make-closure, make-interpreted-closure, and make-byte-code |
Date: |
Mon, 11 Nov 2024 17:04:29 +0100 |
My understanding is that interpreted closures and bytecode are both
closures, just with different restrictions on what each slot can hold.
Given this, I can't help but wonder why we have three functions which
implement the same thing and do so in a completely different manner:
- `make-interpreted-closure' checks each argument individually, makes a
vector of length 6, and passes it to Fvector with NARGS as small as
possible.
- `make-byte-code' checks every relevant argument in one if statement
(and signals an error that nothing else signals), and makes an
arbitrary-long vector via Fvector.
- `make-closure' seems to (unless I am misreading it) copy a closure
(and not a bytecode object as it says), change the constants, and
return the copy.
`make-byte-code' and `make-closure' are essentially copiers.
`make-closure' straightforwardly so, and `make-byte-code' effectively
so, as it is primarily used (in core) in some variation of
(apply #'make-byte-code (concat closure nil))
and on that note, I can't see any reason for `make-byte-code' to allow
an arbitrary number of arguments other than to support the above
pattern, and I personally don't find that to be a compelling case.
Putting aside concerns of backwards compatibility for a moment, what I
would expect is to have a `make-closure', a `copy-closure', and
functions for retrieving (and/or setting) each slot of closures (we
already have something like that in `interactive-form' and
`documentation'), with `make-interpreted-closure' and `make-byte-code'
being very small wrappers around `make-closure'. I lean more towards
the current `make-interpreted-closure' as what `make-closure' should
look like, as that lends itself better to changing the slots around
without breaking code.
I think that it would be agreeable to backwards incompatibly change
`make-closure', as I see exactly one use of `make-closure' in core in
oclosure.el and exactly no uses in melpa or elpa. `make-byte-code' can
also be deprecated in favor of a `make-compiled-closure' with better
interface, so as not to break existing code using `make-byte-code'
(though of course, any moving slots around will break almost all code
using `make-byte-code' regardless; that's why I want this change to
begin with). This doubly so given the structure of closures is supposed
to be an implementation detail.
Some other solution is also fine; my motivation is to make it as
painless as possible to add a new slot to (the middle of) closures (see
https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg01229.html and
https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00039.html for
context).
- Unify make-closure, make-interpreted-closure, and make-byte-code,
Thuna <=