From: akater <nuclearspace@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] Some improvements for cl-flet
Date: Thu, 07 Oct 2021 05:02:23 +0000 [thread overview]
Message-ID: <87pmshqvfk.fsf@gmail.com> (raw)
In-Reply-To: <jwvy27aiy29.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Maybe it might be worthwhile splitting it into 2 or 3 patches so as to
> better see how we got to the level of complexity.
> See more comments below.
Local setfs certainly can be added later (or simply dropped, until
better times). It will simplify the patch.
> Why do we have/need this? Does it work with other things that use
> gv-places, like `push`, `pop`, `cl-callf`, ...? If so, how?
> If not, then we need another approach which does.
I added support for local setfs mostly
- because I decided to implement all features of flet since I'm dealing
with low levels of cl-flet anyway and this might be the last time it
happens;
- and since ignoring local setfs now might make it harder to implement
them in future.
This functionality does not have any more to do with places than
(cl-defmethod (setf ..) ..)
so I guess it has no relation to gv-places, right?
>
> I thought handling `cl-flet` of (setf foo) would amount to calling
> `gv-setter` to get the symbol corresponding to `(setf foo)` and then
> c-flet-binding that symbol instead of `(setf foo).
>
At the very least, gv-setter will fail for local (setf car) and so on.
I don't know how cl-flet should treat such things (in Common Lisp it's
UB) but I saw that cl-flet performs local redefinition of car just fine
so I followed suit.
>> +(defun cl--expand-flet (env body &rest flet-expanders-plist)
>> + "Return a form equivalent to `(cl-flet ,bindings BODY)
>> +where bindings correspond to FLET-EXPANDERS-PLIST as described below.
>> +
>> +ENV should be macroexpansion environment
>> +to be augmented with some definitions from FLET-EXPANDERS-PLIST
>> +to then expand forms in BODY with.
>> +
>> +FLET-EXPANDERS-PLIST should be a plist
>> +where keys are function names
>> +and values are 0-argument lambdas
>> +to be called if the corresponding function name is encountered
>> +in BODY and then only (that is, at most once).
>
> Why "at most once"?
We don't want to end up calling different functions in different
instances of local function calls which share the same name within a
single cl-flet form, for whatever unforseeable reason this might happen
(like poorly written flet-expander or poorly written exp in (func exp)).
The best way to ensure local definitions are consistent is to only
produce the local function once per local function used in the body.
If the local function is not encountered in the body at all, the
corresponding function object (or whatever exp in (func exp) evaluated
to) is never produced. Hence, “at most once”.
Note also that in the use case this patch was motivated by, we only need
to evaluate arbitrary code once per encountered symbol:
(cl--expand-flet macroenv (cdr parsed-body)
'cl-call-next-method (lambda () (push cnm uses-cnm)
(list nil cnm))
'cl-next-method-p (lambda () (push nmp uses-cnm)
(list nil nmp)))
> Can we simplify this so only one of the two is supported?
Maybe but before I reply properly, I'd like to know if you have any
thoughts on
https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg00522.html
(it is relevant).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 865 bytes --]
next prev parent reply other threads:[~2021-10-07 5:02 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-11 12:51 Some improvements for cl-flet akater
2021-09-11 23:32 ` Michael Heerdegen
2021-09-12 3:35 ` akater
2021-09-12 15:38 ` Stefan Monnier
2021-09-13 0:14 ` Michael Heerdegen
2021-09-13 2:26 ` Stefan Monnier
2021-10-07 2:32 ` akater
2021-10-07 18:03 ` Stefan Monnier
2021-10-08 21:57 ` Richard Stallman
2021-10-09 5:23 ` akater
2021-10-09 6:01 ` Michael Heerdegen
2021-10-09 23:37 ` Richard Stallman
2021-10-10 10:41 ` Po Lu
2021-10-10 20:27 ` João Távora
2021-10-10 21:57 ` Stefan Monnier
2021-10-11 0:45 ` [External] : " Drew Adams
2021-10-11 21:16 ` Richard Stallman
2021-10-11 21:26 ` João Távora
2021-10-12 22:42 ` Richard Stallman
2021-10-12 0:05 ` Po Lu
2021-10-12 0:29 ` Robin Tarsiger
2021-10-12 22:43 ` Richard Stallman
2021-10-09 23:33 ` Richard Stallman
2021-10-09 23:33 ` Richard Stallman
2021-10-14 4:00 ` Michael Heerdegen
2021-09-23 22:37 ` [PATCH] " akater
2021-09-23 22:41 ` akater
2021-09-24 7:11 ` João Távora
2021-09-24 15:20 ` [PATCH] Some improvements for cl-flet, and some more akater
2021-09-24 16:22 ` João Távora
2021-09-25 1:28 ` Lars Ingebrigtsen
2021-09-25 8:37 ` João Távora
2021-09-24 20:30 ` [PATCH] Some improvements for cl-flet akater
2021-09-26 6:54 ` Lars Ingebrigtsen
2021-09-26 12:04 ` akater
2021-09-26 12:36 ` Lars Ingebrigtsen
2021-10-03 3:51 ` Stefan Monnier
2021-10-07 5:02 ` akater [this message]
2021-10-07 18:23 ` Stefan Monnier
2021-11-03 12:59 ` akater
2021-11-09 20:37 ` Stefan Monnier
2021-10-09 5:33 ` akater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pmshqvfk.fsf@gmail.com \
--to=nuclearspace@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.