From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Emacs design and architecture. How about copy-on-write? Date: Mon, 25 Sep 2023 15:31:42 +0200 Message-ID: <8734z2e5vl.fsf@dataswamp.org> References: <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <87cyyhc7uu.fsf@dataswamp.org> <83ttrsg9nx.fsf@gnu.org> <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <877conk5ny.fsf@localhost> <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <8734zbyu6o.fsf@dataswamp.org> <835y46e8o9.fsf@gnu.org> <87zg1ixvnc.fsf@dataswamp.org> <87il86nxts.fsf@localhost> <87o7hyx8h2.fsf@dataswamp.org> <87o7hx88ry.fsf@localhost> <87jzsidws8.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17171"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:s8f29UFAziQDFVC8GwVbOLBnafc= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 26 14:41:53 2023 Return-path: Envelope-to: ged-emacs-devel@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 1ql7Nw-0004Bz-P6 for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Sep 2023 14:41:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ql7N6-0006Uv-Ch; Tue, 26 Sep 2023 08:41:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qklgq-000069-84 for emacs-devel@gnu.org; Mon, 25 Sep 2023 09:31:56 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qklgo-0001Ew-FI for emacs-devel@gnu.org; Mon, 25 Sep 2023 09:31:55 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qklgl-0007gV-1V for emacs-devel@gnu.org; Mon, 25 Sep 2023 15:31:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io 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-Mailman-Approved-At: Tue, 26 Sep 2023 08:40:58 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311067 Archived-At: Drew Adams wrote: >> Global/dynamic/special variables are the exception and not >> the norm - yes, as we hear from the name "special" BTW :) - >> and yes, they will have to be locked one by one and for as >> long as it takes for the execution to proceed safely. > > I hate to say it, but one of the points (the only point?) of > global/dynamic/special in Lisp is to be able to affect other > code anywhere, including code that isn't yet written. Yes, again one would have to agree on a general model first. It would not be an abstraction only, but also a blueprint what we want to achieve. Then one would have to go thru all the cases where the global state is interacted with and come up with ways how those cases are to be changed so that they don't break existing code, while also making sense in a multi-thread environment. No solution or implementation are allowed to break existing code, so that would be the minimum. And anything more than that, they would have to make as much sense as possible in the new, multi-threaded environment. Global/dynamic/special variables would be one such case - or rather, several cases, as you can interact with those by means of several Lisp constructs, be it `setq' or `let' or whatever else there is. It would all have to be covered one by one. We now what `setq' does it a global/dynamic/special variable now, in single-threaded Emacs. What would it do in a multi-threaded Emacs? That does not break code written for the old, single-threaded one? And so on. -- underground experts united https://dataswamp.org/~incal