From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Circular records: how do I best handle them? (The new correct warning position branch now bootstraps in native compilation!)
Date: Thu, 30 Dec 2021 13:37:47 -0500 [thread overview]
Message-ID: <jwvpmpe3q7f.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <Yc3jMEiiMI0ROOhI@ACM> (Alan Mackenzie's message of "Thu, 30 Dec 2021 16:49:52 +0000")
>> >> Hmm... circularity is quite normal in data structures, yes.
>> >> But presumably this is only applied to source code where circularity is
>> >> very rare. Could it be that you end up recursing in elements which
>> >> actually aren't part of the source code (and hence can't have
>> >> symbols-with-positions)?
>> > I honestly don't know at the moment.
>> I think it's worth the effort to try and track this down. Maybe we can
>> completely circumvent the problem.
> I don't think there are any such cases.
Hmm... I thought this whole circular records thread started because you
bumped into such a case. I feel like I'm misunderstanding something.
>> So the symposes can end up in 2 places:
>> - in the .elc file: no need to strip the pos here, just make sure the
>> symbols get printed without their position.
> The positions get stripped before the code is dumped to the .elc.
Why bother? You can just have a `print-symbols-without-position` which
you let-bind around the printing code.
>> - elsewhere: that's the problematic part because this only occurs where
>> the source code gets stealthy passed elsewhere, e.g. when a macro
>> calls (put ARG1 'foo ARG2) during the macro expansion (rather than
>> returning that chunk of code in the expansion).
> This isn't a problem. If it is a compiled macro doing this, the
> positions will already be gone from the symbols. If it is from an
> uncompiled macro, XSYMBOL in Feval's subroutines does the Right Thing.
I didn't mean sympos coming from the macro but sympos coming from the
args passed to the macro. Something like:
(defmacro foobar-really (arg1 arg2)
(puthash arg1 arg2 foobar-remember)
`(progn (do-something ,arg1) (do-something-else ,arg2)))
The `remember` property will end up containing symbols-with-pos if
`arg2` contains symbols.
> It's used all over the place. In eval-when/and-compile, it is used
> before the evaluation. It is used before dumping the byte compiled code
> to the file.elc, and before passing this code to the native compiler.
> Several (?most) of the byte-compile-file-form-... functions use it.
> It's used in the newish keymap functions near the end of bytecomp.el, in
> byte-compile-annotate-call-tree, etc. Also in cl-define-compiler-macro,
> and internal-macro-expand-for-load.
Interesting. Why do you need it at so many places?
What is it usually used for?
> Additionally, also from Fput, to prevent symbols with positions
> getting into symbol property lists.
IIUC this is for the kind of example I showed above (tho I used
`puthash` instead of `put`)?
> Yes, I have to do this. I am still debating whether just to do it
> (which might slow things down quite a bit), or to do it in a
> condition-case handler after the recursion has exceeded the 1,600
> max-lisp-eval-depth. I'm inclined towards the latter at the moment.
Using a (weak) hash-table may actually speed things up if you call it
from lots and lots of places and it thus ends up being applied several
times (redundantly) to the same data.
> For other Lisp objects with a read syntax, such as char tables and
> decorated strings, I intend to amend the reader just to output plain
> symbols for them.
Sounds reasonable.
Stefan
next prev parent reply other threads:[~2021-12-30 18:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 21:15 Circular records: how do I best handle them? (The new correct warning position branch now bootstraps in native compilation!) Alan Mackenzie
2021-12-24 13:56 ` Stefan Monnier
2021-12-24 20:37 ` Alan Mackenzie
2021-12-26 20:35 ` Stefan Monnier
2021-12-30 16:49 ` Alan Mackenzie
2021-12-30 18:37 ` Stefan Monnier [this message]
2021-12-31 21:53 ` Alan Mackenzie
2022-01-01 17:31 ` Stefan Monnier
2022-01-07 16:44 ` Alan Mackenzie
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=jwvpmpe3q7f.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/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.