all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: problems with Emacs 28
Date: Tue, 27 Oct 2020 01:29:03 +0100	[thread overview]
Message-ID: <87sga0o6k0.fsf@zoho.eu> (raw)
In-Reply-To: 10bfb59d-23a2-4fb8-8bc6-105ffd486edd@default

Drew Adams wrote:

>>> If users can't depend on it, to let them know if a function might
>>> modify data destructively, then it can mislead, and so be even
>>> more "dangerous". Now, we really need a giant sign saying that you
>>> can't rely on a destructive function's name having a suffix of
>>> `!'.
>> 
>> BTW, we use "destructive" most of the time to denote "might do
>> anything with the original value" (from "destroy). Vs. here the !
>> means "modifies in place" (you can rely on the value being present
>> in the original place).
>
> Yes. In general it means that the "function" might modify data (in
> particular input data).
>
> Most important here is "modify". Second most important is "might".
>
> "Destructive" can be misleading, since if you intend the
> modification then, well, it's doing what you want and expect.

I'm happy to call everything a function but what I remember, and if
I understood it correctly, the terminology was

method - a function belonging to an OOP object

procedure - a function that don't return a value

function - a function that do return a value

destructive - changes the value in the actual argument variables.
It would seem this requires "call by name" or "call by reference", not
"call by value", right? (Unless the value is a memory location,
perhaps...)

side-effect free - the function doesn't do any changes to anything,
this implies non-destructiveness

side-effects - the function can do changes, to the argument variables
but also to other things. Note that, as Mr Adams says, this is often
what is desired

In functional programming, when it is applied as a rulebook rather
than a thought model, e.g., many Haskell programmers, they like to
divide their programs in two parts, one with side-effects, and one
without. This is for different reasons, one advantage would be
modularity, as the side-effect free part can be brought to any other
program without ever screwing anything up.

If it makes sense?

Well, sometimes!

(Please append to the list and make corrections. Complete function
terminology list project!)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal




  reply	other threads:[~2020-10-27  0:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23 16:50 problems with Emacs 28 Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-23 17:33 ` Jean Louis
2020-10-23 18:02   ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-23 18:00 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-24  1:55   ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-24 12:56     ` Stefan Monnier
2020-10-24 12:57     ` Stefan Monnier
2020-10-24  9:46   ` Michael Heerdegen
2020-10-24 17:00     ` Drew Adams
2020-10-24 19:26       ` Michael Heerdegen
2020-10-24 22:11         ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-24 22:08       ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-25 12:13       ` Michael Heerdegen
2020-10-25 14:15         ` Drew Adams
2020-10-27  0:29           ` Emanuel Berg via Users list for the GNU Emacs text editor [this message]
2020-10-27 10:22             ` Michael Heerdegen
2020-10-28 16:21             ` Jens C. Jensen
2020-10-28 17:07               ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-28 17:18               ` Stefan Monnier
2020-10-31 18:26                 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-11-01 13:51                   ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-23 18:16 ` Eli Zaretskii
2020-10-23 18:22   ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-23 18:44 ` Stefan Monnier
2020-10-24  0:13   ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-10-23 19:09 ` Gregory Heytings via Users list for the GNU Emacs text editor
2020-10-24  0:14   ` Emanuel Berg via Users list for the GNU Emacs text editor

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=87sga0o6k0.fsf@zoho.eu \
    --to=help-gnu-emacs@gnu.org \
    --cc=moasenwood@zoho.eu \
    /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.