From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] src/process.c: remove unnecessary setters Date: Sat, 06 Jan 2018 17:03:41 +0200 Message-ID: <83d12n9ghe.fsf@gnu.org> References: <87shjnmeag.fsf@SoraLaptop> <87tw43t94q.fsf@SoraLaptop> <39094a23-3884-68b6-5633-25a6231460f5@cs.ucla.edu> <83wp8yev6w.fsf@gnu.org> <87po6q78ut.fsf@cochranmail.com> <62ac068b-2ec2-af36-78f2-c7fb67ad2ee8@cs.ucla.edu> <87y3lei6eu.fsf@cochranmail.com> <87r2r4jih0.fsf@tromey.com> <83o9m89nce.fsf@gnu.org> <871sj3iaze.fsf@cochranmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1515250936 30082 195.159.176.226 (6 Jan 2018 15:02:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2018 15:02:16 +0000 (UTC) Cc: emacs-devel@gnu.org, tom@tromey.com, robert-emacs@cochranmail.com, dmantipov@yandex.ru, eggert@cs.ucla.edu To: Robert Cochran Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 06 16:02:11 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXpz8-0007Pv-8V for ged-emacs-devel@m.gmane.org; Sat, 06 Jan 2018 16:02:10 +0100 Original-Received: from localhost ([::1]:38624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXq15-0007Xj-Rg for ged-emacs-devel@m.gmane.org; Sat, 06 Jan 2018 10:04:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXq0z-0007XW-09 for emacs-devel@gnu.org; Sat, 06 Jan 2018 10:04:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXq0v-0003NB-QT for emacs-devel@gnu.org; Sat, 06 Jan 2018 10:04:05 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXq0v-0003N7-M8; Sat, 06 Jan 2018 10:04:01 -0500 Original-Received: from [176.228.60.248] (port=2606 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eXq0u-0001SQ-GC; Sat, 06 Jan 2018 10:04:01 -0500 In-reply-to: <871sj3iaze.fsf@cochranmail.com> (message from Robert Cochran on Sat, 06 Jan 2018 01:37:41 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221642 Archived-At: > From: Robert Cochran > Cc: Tom Tromey , eggert@cs.ucla.edu, robert-emacs@cochranmail.com, dmantipov@yandex.ru, emacs-devel@gnu.org > Date: Sat, 06 Jan 2018 01:37:41 -0800 > > Eli Zaretskii writes: > > >> From: Tom Tromey > >> Cc: Paul Eggert , Eli Zaretskii , dmantipov@yandex.ru, emacs-devel@gnu.org > >> Date: Fri, 05 Jan 2018 10:58:19 -0700 > >> > >> >>>>> "Robert" == Robert Cochran writes: > >> > >> Robert> IMO, there's not much of a point in wrapping something so simple in a > >> Robert> funcall. I understand that a good compiler will optimize that away, but > >> Robert> that doesn't really fix the code any. > >> > >> Robert> Whatever reason for leaving these has apparently faded into history, if > >> Robert> my past self is to be believed: > >> > >> IIRC those were introduced to support incremental GC. > > > > Indeed. In general, we have similar setters for window, frame, and > > buffer objects. Do we want to get rid of all of those? And if we do, > > does that mean we abandon all hope for migrating to a more modern GC? > > If the setters in question are tiny wrappers whose entire body is a > straight assignment to a struct member (like all of the ones I removed > with this patch), then IMO yes, they should go away. The value is that these setters allow a much easier switch to a more modern GC, because most such modern GC methods want to know when an object was modified. By removing these setters we in effect say we don't envision any move to a better GC any time soon. IOW, a decision to remove those setters need to consider more than just how thick they are today. It took a non-trivial amount of effort at the time to come up with just the right mix of setters, and we've kept them ever since in the hope that they will be useful to someone who'd want to work on a better GC for Emacs. > If these kinds of setters become necessary, for doing the GC bookkeeping > that you mention for instance, then by all means put them back once they > do something other that merely set a structure memeber to exactly what > was passed as a value and nothing more. Like I said: deciding which setters to put back was a non-trivial job, which took several iterations. And who will even remember at that time that we once had these setters? I'm not saying I object to the removal of these, just that the decision at stake is more than what meets the eye. > My intent is that relatively small changes like this help make the C > parts of Emacs less intimidating. I've noticed a general social > perception that the C parts are intimidating, that people generally > don't want to touch it, and that things are getting to a point where > there are less and less people who understand the C parts. My impression is that people find the C parts intimidating because they are less experienced with C, and therefore feel themselves less "at home" in a large C program. And I don't see how a setter whose name says clearly what it does can possibly intimidate. But once again, this is a side issue. If we want to decide that GC will not change any time soon, I don't object to removing these setters. But if we do remove them, then we should also remove the similar wset_*, fset_*, bset_*, and kset_* functions, and I think we should remove all of them in the same changeset, to make a future restoring them easier. > I feel like the appropriate response then, is to find places like this > where some of the accidental complexity can be made to go away. IME, the complexity of the Emacs internals is entirely elsewhere: in the complex problems the code tries to solve, and in lack of deep enough background information in the docs/comments that would allow newcomers to dive fairly quickly into the code and understand what the code is doing. So I think the contribution of this change to complexity reduction is relatively minor. (But again, I'm not against it.)