help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with Emacs 28


From: Emanuel Berg
Subject: Re: problems with Emacs 28
Date: Tue, 27 Oct 2020 01:29:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]