unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Unify make-closure, make-interpreted-closure, and make-byte-code
@ 2024-11-11 16:04 Thuna
  2024-11-18 20:15 ` Thuna
  0 siblings, 1 reply; 2+ messages in thread
From: Thuna @ 2024-11-11 16:04 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-11-18 20:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-11 16:04 Unify make-closure, make-interpreted-closure, and make-byte-code Thuna
2024-11-18 20:15 ` Thuna

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).