From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: problems with Emacs 28 Date: Tue, 27 Oct 2020 01:29:03 +0100 Message-ID: <87sga0o6k0.fsf@zoho.eu> References: <87lffwhop1.fsf@zoho.eu> <87r1poddpj.fsf@zoho.eu> <87pn58gdnj.fsf@web.de> <3cec75b0-410b-40c7-97c3-d04667c4c04d@default> <877drea4gb.fsf@web.de> <10bfb59d-23a2-4fb8-8bc6-105ffd486edd@default> Reply-To: Emanuel Berg Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2640"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:7GTlQGG84Tmu/8uZbLmltqxebh8= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 27 01:30:10 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXCsL-0000Zd-Vh for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 27 Oct 2020 01:30:09 +0100 Original-Received: from localhost ([::1]:57206 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXCsL-0005Fu-1y for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 26 Oct 2020 20:30:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXCrX-0005E1-Rl for help-gnu-emacs@gnu.org; Mon, 26 Oct 2020 20:29:19 -0400 Original-Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214]:50686 helo=ciao.gmane.io) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXCrV-00075t-QW for help-gnu-emacs@gnu.org; Mon, 26 Oct 2020 20:29:19 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kXCrQ-0009z0-4w for help-gnu-emacs@gnu.org; Tue, 27 Oct 2020 01:29:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/26 20:12:07 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:124725 Archived-At: 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