all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 --]

  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.