[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40671: [DOC] modify literal objects
From: |
Paul Eggert |
Subject: |
bug#40671: [DOC] modify literal objects |
Date: |
Wed, 22 Apr 2020 10:36:16 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 4/19/20 10:32 PM, Drew Adams wrote:
Giving it an existing name (e.g. "constant"), which means
something else
In informal language the word "constant" can mean different things to different
people. If the manual defines the word "constant" to mean "an object whose value
should never change" and it uses that word consistently, then that's OK; the
manual's terminology corresponds closely enough to the informal one. Of course
if we can come up with a better phrase than "constant" then we should use that;
but so far we haven't seemed to be able to.
Explain the gotcha in one place, and if
need to refer to that explanation elsewhere then do so
(link).
Yes, that's what's done now.
If Emacs can crash or remove your home directory,
that's a bug, IMO. We don't document bugs
We should advise Lisp programmers about what they can do safely, and what they
should not do due to Emacs's unfortunate limitations. We already do this in
other dangerous areas (e.g., what happens if you increase max-lisp-eval-depth
too far), and we should do it in this dangerous area too. You're right that we
needn't document in detail what happens if a Lisp program does unsafe things.
we certainly shouldn't let Emacs crash
If we can fix the problem that would be better, yes. However, it's not practical
to do that for Emacs 27 because it is so close to release and any fix would
require major surgery. It's not clear that it's practical to fix things even for
Emacs 28.
Saying some behavior
is undefined is never (in my experience) done knowing
it crashes the program.
Welcome to the wonderful world of undefined behavior. I'm joking of course;
undefined behavior is not a good thing. But here we are.
Maybe say that just reading the '(1 2 3) creates a
list, and that thereafter that same list is used by
the byte compiler.
Thanks, I'll add something along those lines.
- bug#40671: [DOC] modify literal objects, (continued)
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/18
- bug#40671: [DOC] modify literal objects, Drew Adams, 2020/04/18
- bug#40671: [DOC] modify literal objects, Noam Postavsky, 2020/04/18
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/19
- bug#40671: [DOC] modify literal objects, Drew Adams, 2020/04/19
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/19
- bug#40671: [DOC] modify literal objects, Drew Adams, 2020/04/19
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/19
- bug#40671: [DOC] modify literal objects, Drew Adams, 2020/04/20
- bug#40671: [DOC] modify literal objects,
Paul Eggert <=
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/30
bug#40671: [DOC] modify literal objects, Richard Stallman, 2020/04/18
bug#40671: [DOC] modify literal objects, Eli Zaretskii, 2020/04/19
- bug#40671: [DOC] modify literal objects, Mattias EngdegÄrd, 2020/04/19
- bug#40671: [DOC] modify literal objects, Eli Zaretskii, 2020/04/19
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/19
- bug#40671: [DOC] modify literal objects, Drew Adams, 2020/04/19
- bug#40671: [DOC] modify literal objects, Michael Heerdegen, 2020/04/19
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/19
- bug#40671: [DOC] modify literal objects, Michael Heerdegen, 2020/04/19