all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Nicolas Petton <nicolas@petton.fr>,
	Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: Tom Tromey <tom@tromey.com>, emacs-devel@gnu.org
Subject: RE: map-put! and (setf (map-elt ...) ..) on lists
Date: Tue, 18 Dec 2018 09:41:20 -0800 (PST)	[thread overview]
Message-ID: <a1e7e0f5-7497-4699-a8b9-6766b1f55406@default> (raw)
In-Reply-To: <871s6en68c.fsf@petton.fr>

> > My point was that there is no need for a function
> > name to signal that the function so named is
> > "destructive".  The doc string should do that,
> > however.
> 
> It can be very important to know that a function is destructive, I don't
> think it's a should be seen as an internal detail of the function.  IOW,
> I think that whether a function is destructive or not is part of what
> the function does, not how it does it.

It's not an internal detail - agreed.  It's
an important part of what it does (can do).
Very important.

And yet you don't know such behavior from
99.9999% of the existing function names,
do you?

When you write a function that makes use of a
destructive function, and whose action might
itself change something, including, e.g.,
list structure, do you name it in a special
way?  Do you think that others do so?

You can't rely on such naming, because it
Just. Doesn't. Happen.

And if it did happen then such name suffixes
would be all over the place - more noise than
signal - like ignored legalistic warnings
that serve only to protect the warners from
lawsuits.

Much such rightfully gets relegated to the
fine print.  Can we guess why?  Because it's
noise, not signal.  How does it happen that
something _very important_ can become noise?
Too much of it.  When you are warned about
everything you are really not warned about
anything.

Lisp is an imperative, procedural language.
Like that or hate it; it's a fact.  If you
want a declarative language, Lisp ain't it.

One might argue that there are different
degrees or kinds of state modification /
mutation, and thus different sorts of "danger".
Maybe only some kinds merit a DANGER! suffix?

Perhaps you feel that `setq' and `set' are
not sufficiently dangerous to merit renaming
to `setq!' and `set!' (oops, the latter is
Scheme's `setq', it doesn't correspond to
Lisp's `set').  Or perhaps not. `setf!'?
`put!'?  `push!'? `load-library!'?  On and
on...

Or perhaps you'd propose we reserve `!'
for (possible) list modification? sequence
modification?  Something else?

If we're going to have a naming convention
then hey, let's really have a convention.
Seriously.

Regardless of whether we decide to rename
existing functions, if we're going to have
a convention then we should apply it for
everything new.

And we should document it for users,
encouraging them too to respect it.
Otherwise users will fall into pitfalls -
unexpected (because unwarned) gotchas.
Truth in labeling, after all.

Do I think we should have such a convention?
Nope.  Do I think we should use suffix `!'
just here and there, for only a few new
functions?  Nope.  Do I think we should call
`map-put' `map-put!' because it can modify
list structure, hash tables, arrays...?
Nope.

The choices really are these, I think:

1. Put up one big general sign saying,
   "Lisp may be hazardous to your health."

   Oops, I mean, "Lisp is an imperative,
   procedural language.  Be aware that data
   mutation and other state CHANGE HAPPENS."

2. Rigorously put warning signs on everything
   that might modify state, which means
   pretty much everything that might come
   into contact with something that might
   modify state, which means most everything.

I vote for #1.



  reply	other threads:[~2018-12-18 17:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-14 17:32 map-put! and (setf (map-elt ...) ..) on lists Stefan Monnier
2018-12-16 16:32 ` Tom Tromey
2018-12-16 17:37   ` Drew Adams
2018-12-16 18:20     ` Stefan Monnier
2018-12-16 23:06       ` Tom Tromey
2018-12-17  3:16         ` Stefan Monnier
2018-12-17  4:08       ` Stefan Monnier
2018-12-17 11:41         ` Nicolas Petton
2018-12-17 16:06           ` Eli Zaretskii
2018-12-17 16:07           ` Drew Adams
2018-12-18 10:11             ` Nicolas Petton
2018-12-18 13:56               ` Stefan Monnier
2018-12-18 15:42                 ` Drew Adams
2018-12-18 15:34               ` Drew Adams
2018-12-18 15:47                 ` Stefan Monnier
2018-12-18 16:34                 ` Nicolas Petton
2018-12-18 17:41                   ` Drew Adams [this message]
2018-12-18 20:44                     ` Nicolas Petton
2018-12-16 18:21     ` Stefan Monnier
2018-12-17 11:38 ` Nicolas Petton

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=a1e7e0f5-7497-4699-a8b9-6766b1f55406@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=nicolas@petton.fr \
    --cc=tom@tromey.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.