From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Daniel Colascione <dancol@dancol.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r116995: cl-lib defstruct introspection
Date: Mon, 21 Apr 2014 18:03:18 -0400 [thread overview]
Message-ID: <jwvoazunyg1.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <53555822.3080007@dancol.org> (Daniel Colascione's message of "Mon, 21 Apr 2014 10:40:50 -0700")
> That's new. Using the whole ChaneLog message has been a recommendation,
> but never a requirement.
For `elpa', that's true, but for `emacs' it's always been a requirement,
on the premise that this should/will allow us to drop the ChangeLog
files at some point.
> Now there's one more step on the commit path, and a useless one at
> that: the changelog entry is available in the change itself and in the
> message to the mailing list.
C-x v v can copy the message from ChangeLog for you (and set Author:
and Fixes: at the same time), so it's not so bad.
The way to fix this, is to make ChangeLog unneeded. First step on this
path is to provide some way to make `C-x 4 a' usable without ChangeLog.
>>> +The @code{cl-defstruct} package also provides a few structure
>>> +introspection functions.
>> I'm curious: when/where did you bump against a need for that?
> I have a few private macros that lexically bind structure slots,
Which part makes it impossible/impractical to use standard accessors for
that?
> and this information is also needed for some interface-generation work
> I'm thinking of doing.
Not sure what "interface-generation" means, but it sounds interesting.
>>> +@defun cl-struct-set-slot-value struct-type slot-name inst value
>> We don't need this, since we can always use setf instead.
> So? We have both (setf (aref ...) ...) and (aset ...).
That's only because (setf (aref ...) ...) needs to macroexpand to something.
[ It's one of the differences between Common-Lisp and Elisp. ]
In your case, (setf (cl-struct-slot-value ...) ...) can macroexpand to
something without needing cl-struct-set-slot-value. Actually, in order
for (incf (cl-struct-slot-value ...)) not to compute the offset twice,
(setf (cl-struct-slot-value ...) ...) will end up expanding to something
else than a call to cl-struct-set-slot-value.
> That test was there in cl-check-type. The test doesn't make sense to me
> either. We should drop it in both places if we drop it in cl-the.
Great, let's drop it then. Thanks.
>>> +(cl-define-compiler-macro cl-struct-slot-value
>> Please use (declare (compiler-macro ..)).
> Why? In both cases, the compiler macro is written out-of-line and in
> both cases, we just stick the compiler macro on the symbol's plist.
Because that's the style we use in Elisp.
Note that (declare (compiler-macro ..)) can provide the compiler-macro
"inline" or "out-of-line".
>> I guess this goes back to the earlier question about when/where the use
>> for this functionality came up.
> Unless we're using this functionality in generated code where, while the
> slot is constant, it's more convenient to use that slot's name than to
> try to determine the accessor name.
Ah, so it's for code generated based on cl-struct-slot-info?
Right, that makes sense.
Stefan
next prev parent reply other threads:[~2014-04-21 22:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1Wbhqn-0001CJ-4X@vcs.savannah.gnu.org>
2014-04-20 12:49 ` [Emacs-diffs] trunk r116995: cl-lib defstruct introspection Stefan Monnier
2014-04-23 12:56 ` Stefan Monnier
2014-04-21 15:38 ` Stefan Monnier
2014-04-21 17:40 ` Daniel Colascione
2014-04-21 22:03 ` Stefan Monnier [this message]
2014-04-21 22:26 ` Daniel Colascione
2014-04-22 2:03 ` Stefan Monnier
2014-04-22 2:07 ` Daniel Colascione
2014-04-22 3:28 ` Stefan Monnier
2014-04-23 3:18 ` Declaim and proclaim (Was: Re: [Emacs-diffs] trunk r116995: cl-lib defstruct introspection) Daniel Colascione
2014-04-23 13:14 ` Declaim and proclaim Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvoazunyg1.fsf-monnier+emacsdiffs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=dancol@dancol.org \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).