[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
scratch/oclosure 5c8b918c2d: * lisp/emacs-lisp/oclosure.el: Update comme
From: |
Stefan Monnier |
Subject: |
scratch/oclosure 5c8b918c2d: * lisp/emacs-lisp/oclosure.el: Update comment near beginning |
Date: |
Sun, 2 Jan 2022 12:27:22 -0500 (EST) |
branch: scratch/oclosure
commit 5c8b918c2da66591852b17ee171f450f8a00aec6
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Commit: Stefan Monnier <monnier@iro.umontreal.ca>
* lisp/emacs-lisp/oclosure.el: Update comment near beginning
---
lisp/emacs-lisp/oclosure.el | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/lisp/emacs-lisp/oclosure.el b/lisp/emacs-lisp/oclosure.el
index a338d9183d..b9ec070624 100644
--- a/lisp/emacs-lisp/oclosure.el
+++ b/lisp/emacs-lisp/oclosure.el
@@ -101,26 +101,27 @@
;;; Code:
-;; Slots are currently immutable, tho they can be updated functionally
-;; via the "copiers": we could relax this restriction by either allowing
-;; the function itself to mutate the captured variable/slot or by providing
-;; `setf' accessors to the slots (or both), but this comes with some problems:
-;; - mutation from within the function currently would cause cconv
-;; to perform store-conversion on the variable, so we'd either have
-;; to prevent cconv from doing it (which might require a new bytecode op
-;; to update the in-closure variable), or we'd have to keep track of which
-;; slots have been store-converted so `oclosure--get' can access their value
-;; correctly.
+;; Regarding mutable slots:
+;; - Mutation from within the function currently causes cconv
+;; to perform store-conversion on the variable. If we want to avoid that
+;; we'd require a new bytecode op to update the in-closure variable,
+;; or we'd have to keep track of which slots have been store-converted so
+;; `oclosure--get' can access their value correctly.
;; - If the mutated variable/slot is captured by another (nested) closure
-;; store-conversion is indispensable, so if we want to avoid store-conversion
-;; we'd have to disallow such capture.
+;; store-conversion might be indispensable, so if we want to avoid
+;; store-conversion we'd have to disallow such capture.
;; TODO:
-;; - `oclosure-cl-defun', `oclosure-cl-defsubst', `oclosure-defsubst',
`oclosure-define-inline'?
+;; - `oclosure-(cl-)defun', `oclosure-(cl-)defsubst', `oclosure-define-inline'?
;; - Use accessor in cl-defstruct.
;; - Add pcase patterns for OClosures.
-;; - mixins.
-;; - class allocated slots? code allocated slots?
+;; - mixins and anonymous OClosure types.
+;; - class-allocated slots?
+;; - code-allocated slots?
+;; The `where' slot of `advice' would like to be code-allocated, and the
+;; interactive-spec of commands is currently code-allocated but would like
+;; to be instance-allocated. Their scoping rules are a bit odd, so maybe
+;; it's best to avoid them.
(eval-when-compile (require 'cl-lib))
(eval-when-compile (require 'subr-x)) ;For `named-let'.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- scratch/oclosure 5c8b918c2d: * lisp/emacs-lisp/oclosure.el: Update comment near beginning,
Stefan Monnier <=