unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: Alan Mackenzie <acm@muc.de>
Cc: 25461@debbugs.gnu.org
Subject: bug#25461: [Patch]: Missing doc strings for "," and ",@".
Date: Sat, 21 Jan 2017 03:26:06 +0100	[thread overview]
Message-ID: <87y3y5cfnl.fsf@web.de> (raw)
In-Reply-To: <20170120165856.GA3384@acm.fritz.box> (Alan Mackenzie's message of "Fri, 20 Jan 2017 16:58:56 +0000")

Hello Alan,

> pcase causes ` to be expanded by the macro \`--pcase-macroexpander in
> place of the macro \`.  What is that if it is not pcase redefining `?

pcase patterns are not evaluated normally.  When ` is used in patterns,
the definition of ` is not consulted.  Just like in

(let ((l '(\` 1 2)))
  (when (eq (car l) '\`)
    (apply #'+ (cdr l))))
==> 3

Is that code redefining "`"?

You mean something different with the term "definition": a complete
summarisation of the semantics of something in any context.  Something
like that doesn't exist in a programmable extensible language like Lisp.


> I disagree with you, here.  I'm describing the simple straighforward
> normal effect of ,.  I don't understand why you're making such a big
> deal out of it.

I don't want that we change the docs to the worse.


> > ... because it is undefined.
>
> It is defined.  I intend that definition to be in a doc string.

It is implicitly given a meaning by the implementation of "`".  That's
why it's documented in the documentation of "`".  For the same reason
that there is no separate documentation for :group just because it has a
meaning in defcustom, or there is no mentioning in the docstring that
the symbol `error' has a different meaning as car of a list that is an
error handler in condition-case, or that car has a different meaning in
(setf (car something) ...) or...

All these examples appear in symbolic expressions (i.e. lists) that are
not evaluated normally.  Like in the tiny example above.  If we try to
mention what a symbol potentially could mean in any sexp that is not
evaluated normally in this symbol's docstring, our documentation would
become very messy, because lists that are not evaluated normally are
very common in Lisp.  That's why we normally collect this information in
the documentation of the functions/macros that implement this meaning.
This is not a problem because it's easy to look at the context and
consult the documentation of the surrounding form.


> > So how it is used is arbitrary.
>
> If that were the case, Emacs wouldn't even build.

The introduction of pcase didn't cause Emacs not to build.  Simply
because it didn't change the definition of `.


> > We should not say that "," "does" something, because this makes no
> > sense and leads a person reading this to false assumptions.
>
> It will enable them to understand code they are reading, and to start
> writing ` constructs themselves.

But it won't really enable them to understand how it works.


> Here is the latest proposed version of the doc string for ,,
> incorporating some of the comments you've made.
>
>
>         "`,' causes the next form to be evaluated and inserted.
>     It occurs in `\\=`' constructs.
>
>     For example:
>
>     b              => (ba bb bc)            ; assume b has this value
>     \\=`(a ,b c)      => (a (ba bb bc) c)   ; insert the value of b
>
>     See also `\\=`' and `,@'.
>
>     (Note that ``' constructs (including `,'s) sometimes have different
>     semantics.  This occurs, for example, with the macro `pcase' and other
>     macros with similar names.")

I still think it's an error to describe a global semantics that as such
isn't existent.

I would rather prefer a wording (sorry if it's poor, my English is not
so super...) like

  ", before a symbolic expression X forms a read syntax that the Lisp
  reader expands like ,X -> (, X).  Such symbolic expressions have a
  special meaning in backquote forms (see ``') and in `pcase' patterns -
  see there."

I think it would be ok to append your backquote example above.


Regards,

Michael.





  reply	other threads:[~2017-01-21  2:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 21:22 bug#25461: Missing doc strings for "," and ",@" Alan Mackenzie
2017-01-17 19:34 ` Glenn Morris
2017-01-17 19:56   ` Alan Mackenzie
2017-01-17 20:36     ` Andreas Schwab
2017-01-17 20:41       ` Alan Mackenzie
2017-01-17 20:53         ` Andreas Schwab
2017-01-18  1:44         ` Michael Heerdegen
2017-01-18 19:28           ` Alan Mackenzie
     [not found] ` <handler.25461.B.148460180922707.ack@debbugs.gnu.org>
2017-01-18 19:43   ` bug#25461: [Patch]: " Alan Mackenzie
2017-01-19  0:16     ` npostavs
2017-01-19 17:37       ` Alan Mackenzie
2017-01-19 18:10         ` Noam Postavsky
2017-01-19 18:36           ` Alan Mackenzie
2017-01-20  0:24             ` Michael Heerdegen
2017-01-19  2:23     ` Michael Heerdegen
2017-01-19 17:58       ` Alan Mackenzie
2017-01-20  0:12         ` Michael Heerdegen
2017-01-20 16:58           ` Alan Mackenzie
2017-01-21  2:26             ` Michael Heerdegen [this message]
2017-01-21 15:56               ` Alan Mackenzie
2017-01-21 20:46                 ` bug#25461: [Patch #2]: " Alan Mackenzie
2017-01-24  1:58                   ` Michael Heerdegen
2017-01-24 19:43                     ` Alan Mackenzie
2017-01-24  4:01                   ` npostavs
2017-01-24 19:39                     ` Alan Mackenzie
2017-01-24 20:00                       ` Noam Postavsky
2017-01-23 19:09               ` bug#25461: [Patch]: " 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

  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=87y3y5cfnl.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --cc=25461@debbugs.gnu.org \
    --cc=acm@muc.de \
    /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).