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: Emacs design and architecture. How about copy-on-write? Date: Fri, 22 Sep 2023 23:14:41 +0200 Message-ID: <878r8xewqm.fsf@dataswamp.org> References: <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> <83sf7acp86.fsf@gnu.org> <87led2x8ao.fsf@dataswamp.org> <83r0mtaupr.fsf@gnu.org> <87pm2ae19p.fsf@dataswamp.org> <83lecy5hps.fsf@gnu.org> <87h6nmdwph.fsf@dataswamp.org> <83fs3658zv.fsf@gnu.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="2460"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:pMQek5ctxYhVJTAAvHg/oFYYF44= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 23 07:29:33 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 1qjvCv-0000Vr-Fe for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Sep 2023 07:29:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjvC3-0001ab-Jd; Sat, 23 Sep 2023 01:28:39 -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 1qjnUE-0000bF-HD for emacs-devel@gnu.org; Fri, 22 Sep 2023 17:14:54 -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 1qjnUC-0007qR-NA for emacs-devel@gnu.org; Fri, 22 Sep 2023 17:14:54 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qjnUA-0009qH-MF for emacs-devel@gnu.org; Fri, 22 Sep 2023 23:14:50 +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: Sat, 23 Sep 2023 01:28:37 -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:310992 Archived-At: Eli Zaretskii wrote: > It is impossible in Emacs to write a useful Lisp program > that doesn't rely on global variables and other parts of the > global state. You can only write toy programs without that. Lisp programs are not toy programs just because they don't use global variables. One can reduce the reliance on global variables to a huge degree with various methods. But that's another discussion. Because, if one is unallowed to break existing code implementing an envisioned multi-threaded, multi-core model one would have to deal with them, and it would then not matter if they are few or if they are many in that regard. But note that such a solution would favor any program that would minimize their use, since those would have much less overhead to deal with them, obviously. That, however, is a good thing as it would favor a sound programming style that minimize their use. Again, first one would have to agree on a model how things would work. Say that we go for the idea that each thread has a superstructure of local variables, that would be accessible as if they were globals. In a way, this would not be unlike lexical `let'-closures which can also be used as if they were globals, and that is one of the use cases of that method BTW. Second, one would have to identify all Lisp constructs that interact with the global state. Without changing how those are used, one would have to think - what do they mean in the new, thread model? Of many possibly interpretations, which ones do not contradict how they were previously used? This will have to be done on a case-by-case basis. One could start with the most obvious cases, i.e. `setq', `setf', `let', and so on. It sounds like a lot but actually don't have to be that much. Because first, there are a limited number of such constructs. Second, even tho in terms of implementation it would have to be done case-by-case, if one can identify a good way of solving it for on such case, it is likely that method can be brought over to the rest quite easily. -- underground experts united https://dataswamp.org/~incal