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



  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

* 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 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.