unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tomas Hlavaty <tom@logand.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
Subject: Re: Declaring Lisp function types
Date: Sat, 16 Mar 2024 14:39:24 +0100	[thread overview]
Message-ID: <87v85mthwz.fsf@neko.mail-host-address-is-not-set> (raw)
In-Reply-To: <86wmq3732h.fsf@gnu.org>

On Fri 15 Mar 2024 at 20:38, Eli Zaretskii <eliz@gnu.org> wrote:
>> all cases are grep-unfriendly
>
> What do you mean by that?
> Please tell more: what would you like to grep for and why?

Because good names help working with code bases.

(Almost like being given a direct link (like URL) instead of
instructions to go that page, click foo then click bar then search for
baz...)

In the context of "Declaring Lisp function types", grep gives too many
false positives when searching for the symbol 'function' or 'type'.
Some people suggested more complex regexp to match the declare sexp but
that breaks down pretty quickly.  A better, more unique symbol name
instead of 'function' or 'type' would be much easier to find.

Looking at

   (info "(elisp)Declare Form")

there are examples of good and bad names for declare spec properties.

Good; try searching for these:

   (rg "~/mr/emacs" "advertised-calling-convention")
   (rg "~/mr/emacs" "side-effect-free")
   (rg "~/mr/emacs" "no-font-lock-keyword")

Bad; try searching for these:

   (rg "~/mr/emacs" "pure")
   (rg "~/mr/emacs" "speed")

Interestingly, the info page above says that the speed property
"specifies the value of native-comp-speed in effect for native
compilation of this function".  If the property was called
native-comp-speed, it

- would be more correct,

- it would be easier to search for,

- I could even M-. on the symbol and jump automatically to the
  definition and see the documentation with minimal effort and
  distraction,

- I would even see helpful text as an eldoc message and see possible
  values just by placing cursor on the symbol name.

etc

Try this in elisp-mode:

(defun foo (a b)
  (declare (integer a b)
           (function a b)
           (type a b)
           (speed -1)
           (native-comp-speed -1)
           (advertised-calling-convention)
           (side-effect-free)
           (no-font-lock-keyword)
   )
  (+ a b 42))

Place your cursor on integer, function, type, speed, native-comp-speed,
advertised-calling-convention, side-effect-free, no-font-lock-keyword
and watch the difference in eldoc message, try M-. or rgrep emacs
codebase etc.

The symbol "function" already has specific meaning.  Using it as a
declare spec property name is just bad.  For example, eldoc or M-. shows
something unrelated to "Declaring Lisp function types".

The other symbols do not show or lead to anything, those are dead-ends
magically doing something to the codebase without me being able to use
usual tools to understand and navigate them.  This gap could be bridged
by defining dummy function/macro that would show the right arguments and
documentation and also display useful eldoc message.  For example like
this:

(defun side-effect-free (val)
  "If VAL is non-‘nil’, this function is free of side effects, so
   the byte compiler can ignore calls whose value is ignored.
   This is the same as the ‘side-effect-free’ property of the
   function’s symbol, *note Standard Properties::."
  (error "side-effect-free is not meant to be called"))

But maybe it would be possible to structure the code in such a way that
this dummy would not be needed, like the case of the symbol
"native-comp-speed" (if it was called native-comp-speed instead of
speed).

Searching for no-font-lock-keyword does not show any declare definition.
Is it not used for anything?

Elisp has great tools for navigating and understanding code, why work
against them?  Lisp symbols are a good concept supported by various
tools; use them, give them good names and all those tools will work as
usual and be very helpful in many contexts.



  reply	other threads:[~2024-03-16 13:39 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 16:02 Declaring Lisp function types Andrea Corallo
2024-02-23 23:35 ` Adam Porter
2024-02-24  7:10   ` Eli Zaretskii
2024-02-24  8:53     ` Tomas Hlavaty
2024-02-24  9:08       ` Adam Porter
2024-02-24  9:24         ` Andrea Corallo
2024-02-24 15:13           ` Tomas Hlavaty
2024-02-24 15:21             ` Tomas Hlavaty
2024-02-24 15:24               ` Tomas Hlavaty
2024-02-24  8:56     ` Adam Porter
2024-02-24 10:03       ` Eli Zaretskii
2024-02-25  7:35         ` Adam Porter
2024-02-24  9:21   ` Andrea Corallo
2024-02-25 17:04 ` Alan Mackenzie
2024-02-25 17:15   ` Eli Zaretskii
2024-02-25 17:16   ` [External] : " Drew Adams
2024-02-26 16:25   ` Andrea Corallo
2024-02-29  3:50   ` Richard Stallman
2024-02-29  6:10     ` Adam Porter
2024-02-29  9:02     ` Andrea Corallo
2024-02-26  3:38 ` Richard Stallman
2024-02-26 16:38   ` [External] : " Drew Adams
2024-02-26 16:54     ` Eli Zaretskii
2024-02-26 17:44       ` Andrea Corallo
2024-02-26 16:52   ` Andrea Corallo
2024-02-26 18:10     ` Tomas Hlavaty
2024-03-02 21:19 ` Stefan Monnier via Emacs development discussions.
2024-03-03  9:52   ` Andrea Corallo
2024-03-03 14:52     ` Stefan Monnier
2024-03-03 17:31       ` Andrea Corallo
2024-03-03 18:13         ` Stefan Monnier
2024-03-15 16:49 ` Andrea Corallo
2024-03-15 18:19   ` Tomas Hlavaty
2024-03-15 18:38     ` Eli Zaretskii
2024-03-16 13:39       ` Tomas Hlavaty [this message]
2024-03-16 14:06         ` Eli Zaretskii
2024-03-16 14:56           ` Tomas Hlavaty
2024-03-16 15:43             ` Emanuel Berg
2024-03-16 15:44             ` Eli Zaretskii
2024-03-16 15:54               ` Emanuel Berg
2024-03-18  8:55               ` Lele Gaifax
2024-03-16  0:01   ` Adam Porter
2024-03-18  9:25     ` Andrea Corallo
2024-03-26 10:13   ` Andrea Corallo
2024-03-26 10:28     ` Christopher Dimech
2024-03-26 12:55     ` Eli Zaretskii
2024-03-26 16:46       ` Andrea Corallo
2024-04-29 17:48         ` Andrea Corallo
2024-04-29 17:55           ` Stefan Monnier
2024-04-29 18:42             ` Andrea Corallo
2024-04-30 14:55           ` Eli Zaretskii
2024-04-30 18:29             ` Stefan Monnier
2024-05-01 20:57               ` Andrea Corallo
2024-05-01 21:06                 ` Stefan Monnier
2024-05-02  6:16                   ` Eli Zaretskii
2024-05-02 10:16                   ` Andrea Corallo
2024-05-02  6:15                 ` Eli Zaretskii
2024-05-02 10:12                   ` Andrea Corallo
2024-05-02 11:15                     ` Eli Zaretskii
2024-05-02 13:20                     ` Stefan Monnier
2024-05-01 20:54             ` Andrea Corallo
2024-05-02 10:22               ` Eli Zaretskii
2024-05-02 15:18                 ` Andrea Corallo
2024-05-02 16:32                   ` Eli Zaretskii
2024-03-26 13:05     ` Mattias Engdegård
2024-03-26 13:44     ` Stefan Monnier
2024-03-26 14:28     ` Joost Kremers
2024-03-26 14:37       ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2024-03-16  7:46 Arthur Miller
2024-03-16 15:46 ` Emanuel Berg
2024-03-18  9:02 ` Andrea Corallo
2024-03-18  9:58   ` Arthur Miller

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=87v85mthwz.fsf@neko.mail-host-address-is-not-set \
    --to=tom@logand.com \
    --cc=acorallo@gnu.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=stefankangas@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 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).