all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Philipp <p.stephani2@gmail.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 43557@debbugs.gnu.org
Subject: bug#43557: 28.0.50; Please document which objects are mutable and which are not
Date: Sat, 05 Jun 2021 11:15:05 -0400	[thread overview]
Message-ID: <jwvwnr8xsbc.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> (Philipp's message of "Fri, 4 Jun 2021 15:56:12 +0200")

> Assume you have the following (nonsense) function, with unknown implementation:
>
> (defun my-cons ()
>   "Return a cons cell consisting of the integers 1 and 2."
>   ...)
>
> I. Given only that information and the manual, is the following code valid
> (i.e. can't trigger undefined behavior in any case)?
>
> (setcar (my-cons) 5)

I don't think we want to labels this as "undefined" or "invalid"
(Emacs and Emacs Lisp tries hard to avoid enforcing abstraction
boundaries, and relies instead on softer forms of discipline), but I'd
say that using `setcar` above is risky because the user has no guarantee
about what it may impact.

I think the rule is basically, that you should only ever use `setc[ad]r`
on cons cells you yourself created.  But indeed the manual fails to
document which functions guarantee to return "fresh" new cells, which
makes it hard to know which cells "you yourself created".

> II. Which of the following implementations of `my-cons' is correct
> (i.e. follows the rules of Emacs Lisp as described in the manual)?

All of them.

> From what I can see there are four options:
>
> 1. Unless otherwise specified, objects are mutable.  Then the `setcar' form
> is valid, and only implementation (b) is correct.
> 2. Unless otherwise specified, objects are immutable.  Then the `setcar'
> form always triggers undefined behavior, and only implementation (a)
> is correct.
> 3. Unless otherwise specified, the objects that forms return are of
> unspecified mutability (i.e. they can be mutable or immutable).  Then the
> `setcar' form is invalid because the caller of `my-cons' can't assume that
> its return value is mutable, and all three implementations of `my-cons'
> are correct.
> 4. Mutability of the return object must be specified in all cases.
> Then none of the implementations is correct, since none of them specifies
> the mutability of the returned cons object.

I think we have (3).


        Stefan






  reply	other threads:[~2021-06-05 15:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  8:29 bug#43557: 28.0.50; Please document which objects are mutable and which are not Philipp Stephani
2020-10-15 15:34 ` Lars Ingebrigtsen
2020-10-31 15:54   ` Philipp Stephani
2021-06-03 14:41     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-04 13:01       ` Philipp
2021-06-04 13:56         ` Philipp
2021-06-05 15:15           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-07-05 18:55             ` Philipp
2021-07-05 20:34               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-04 13:26       ` Dmitry Gutov

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=jwvwnr8xsbc.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=43557@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=p.stephani2@gmail.com \
    /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.