From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Q: BLV for function slots + BL obarray/hmap for symbol lookup? Date: Sun, 23 May 2021 11:00:44 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29022"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 23 11:04:08 2021 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 1lkk1n-0007EL-8x for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 11:04:08 +0200 Original-Received: from localhost ([::1]:52336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkk1k-0002W7-PK for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 05:04:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkjyd-0001Na-C9 for emacs-devel@gnu.org; Sun, 23 May 2021 05:00:51 -0400 Original-Received: from mail-am7eur06olkn2036.outbound.protection.outlook.com ([40.92.16.36]:8224 helo=EUR06-AM7-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkjyZ-0002Ol-PR for emacs-devel@gnu.org; Sun, 23 May 2021 05:00:51 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MP+5ZZGPXzm+2vKFJ/g1MTXKEf1gJCW437xaYZv3cRj6xCld6jp0JPO5X7hWNlUmuWw3474wE7SBFdtgxxIOePL+/K3AbGGQ7Q4oBvHbLrnGKhucPpf+djtNz3dx6WJW1muMZYmcC/ARDN8/eFXQwBhd/YPyUf9i8Jl629wWDXjhd7dwetHYTpPDaLBBRqUHh66H3UBkX0F0OtzXcJJ/RMFpBYAa5MeuRqgDePcThcv3HnzENMLW5ddLHK8DbQFGTdS2NwEyDu+OLPbafIh5vCiHkkT70k1JKryiIY9gjk/bEoYx6CfwpOOE2xoPRLjsh7Xl/bgE5I+7tvglvk66zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KJY4citKrpC0bo4P+rwE63BMw8Ilet0jlW3fzVZhU6M=; b=Prl5FtQ26PvloThzMC1NwuKiQAYWZkFKuqTmJLqKUvPRNTgJbnbvlFc4rU552MRFhiaE+dJ2HzBtlznwqAwoW57H1tnGZJks7OAzhoHUXSLm2svyoD2IpLDrN3DOdM4gP0eI0pqjhmc0WeaMwcUCkWhTBescZQzqNsVQKPtWpOt2LPNae6DxYwZZtGIJ3l2Iksis6vl+itKQL7wABOLEMhxixb17rIHC7X8Px+FloVClhE3kKzqPT21JUM3qhibZ+zndGGLiwyJrkCKQxZsL47PbMlTrZx3ncxfs+wNhokv/ZpTp13ntwtzKako/O9CB7ThEwiNVIC3HUSz/mb/DBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KJY4citKrpC0bo4P+rwE63BMw8Ilet0jlW3fzVZhU6M=; b=MEuVbfo70c81YC1++veP3jaDaGpSYOQyD9z/qskpVFzQVCjb2TyKTdEPGzkMXEf6ZlXbubd2dyqTVnEdeosvwKNjh4frchF8WFv4tXqTpbxgwRTTQOriWhhNkKMh9/hEYbKq33HEeV7aFmaKy4m+i7WLZPzKg6GBYlxaghelnzaMiK7Jx+LXhjj3VMDw5Ywmn2EoUTe8mbJqPARKsrQH7B3fBrVmWTB2k3DHtOBF2CsgzgeIj4yVureOjbtx2TeV3J/EoDc99bMx0twIlcad433aoOc8vu1lJOEdeq8T2iLpbDbCUlA1QFcq5+T+WUm7snMHuMxrQ8GLAdwa4AC6DA== Original-Received: from DB8EUR06FT061.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc35::42) by DB8EUR06HT234.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc35::214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25; Sun, 23 May 2021 09:00:44 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2a01:111:e400:fc35::4b) by DB8EUR06FT061.mail.protection.outlook.com (2a01:111:e400:fc35::465) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25 via Frontend Transport; Sun, 23 May 2021 09:00:44 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:2E4B19ACAFAD3FBA38F748B726E3A212ECF66862C393CA01C18A1184A4D43A13; UpperCasedChecksum:DA9F7F6F8F91A63B34685E3DD6534FF07AF8BDFFCB2367832121DA1C926D8AE6; SizeAsReceived:7650; Count:46 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::d1c1:2a0d:3b2b:4591]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::d1c1:2a0d:3b2b:4591%7]) with mapi id 15.20.4150.027; Sun, 23 May 2021 09:00:44 +0000 In-Reply-To: (Stefan Monnier's message of "Sat, 22 May 2021 23:25:22 -0400") X-TMN: [Ek6fRsH2fSkbAcH2L8JBrVRStqUuizT6] X-ClientProxiedBy: AM7PR02CA0008.eurprd02.prod.outlook.com (2603:10a6:20b:100::18) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <82sg2dq0xv.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from HP-Laptop.homepc (81.232.177.30) by AM7PR02CA0008.eurprd02.prod.outlook.com (2603:10a6:20b:100::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.23 via Frontend Transport; Sun, 23 May 2021 09:00:44 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 46 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 4cbb4792-47e4-4f54-dd20-08d91dc93fb8 X-MS-TrafficTypeDiagnostic: DB8EUR06HT234: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gWUq2BAAbzgwlhdvWqSjV4w+gAnYaZHadimuGo9JkWU551caq4jrL+KIyqcnU0RImS2olTtVTb26bXBbAx9BqlHtLZB4w+K3sisbFn2pWoGLBd/ghzLAdvIJAHs/gN0EOAg++wCr6PWHYqUvw1Kb/XutN+KDzCtok7JxRH/3Zlg+S/xt+VZ8cLNlmqOGEtRVzV2gPEYEGJ3y6kiuv0a96ZItCoYXwdkWPBYwMfxEBcGtYi6TjoSVAAZ6jjfKMcLjub7wv1OYjqY6+tfoD0kraJhnLKO9+L44JKL5mcc9Ismhh8Hm7bcnEQuJbO7nirfRFedb6XGGHZCHFQGNHicBxieJVnYWDA+05lo3pRgHEPUJl/8LQrZIzsvuclDb1uxJxLeeIEvUbBBzcyW44dpV0Q== X-MS-Exchange-AntiSpam-MessageData: srQFKGPELmVFHqepqmJIp5dM4tatn0E9I5WRIg6+xtvJ2JEMLt38eLyKNKMokGoEvwlY6tMJdz5X+pLkLnLY8QqPW++tuszlnspu1HXYzvf8IaRqe0XA6LQR8fUAeWpPQ+mgzn7ryxPJHb45wWwzsw== X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4cbb4792-47e4-4f54-dd20-08d91dc93fb8 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2021 09:00:44.8081 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DB8EUR06FT061.eop-eur06.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8EUR06HT234 Received-SPF: pass client-ip=40.92.16.36; envelope-from=arthur.miller@live.com; helo=EUR06-AM7-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:269653 Archived-At: Stefan Monnier writes: >> Ok, there you have something interesting. In which way? If you have time >> to expand on that one. It is already possible to use custo obarray, but >> we have to tell Emacs which obarray to use. I would like it to sort of >> happen automatically if there is a buffer local one. Sort of. No idea >> what would happen if there were more than one local :-). > > I have the impression that your needs are a bit vague ;-) I didn't want to write too long last time. I have been experimenting with a little framework last 3 days, and I am quite sure I need some kind of namespace, buffer local would be perfect in this case. I don't wish to post any code on a public list atm, untill I am done with it. A short sketch is: I have derived elisp mode, and I setup a sort of a "workbook" with some predefined environment. There can be several "workbooks" open at a time, each one is a mini-application, domain specific. User writes elisp code, but since it is a domain specific, there may (and will) be lots of variables and functions with same name, so they have to be insulated from each other. They also won't do sense in rest of Emacs, but Emacs will need to be able to read and eval each workbook. I also don't wish to force prefix usage since it would be very tedious, and bit contraproductive in context of a simple domain specific framework. I could impose restriction on one workbook at a time, but there is still risk of stepping over some Emacs function. > E.g. which buffer should be used to resolve the "buffer-localness"? > The one when `intern` is called or the one when the already-interned > symbol is used? I am not sure I understand what you mean here. The rule would be same as for buffer local vars, but they would work on symbol level instead of variable slot level, at least conceptually. If "local obarray" is declafed in a buffer, all interning would go to that one, like all set/qset set's the local vaalue if there is one. The locally interned symbol would automatically shadow the global one, and in buffers where there is no local obarray the global one would be used. Maybe obarray is not needed, maybe we could just somehow "make-local-symbol" instead of "make-local-variable"? I don't know, I asked because I guess person(s) who implemented the mechanism probably had the thought themselves and decided for some reason to go just for variable slot and not entire symbol. > Maybe you'd be interested in the effort to add some kind of namespace > mechanism by adding some "prefix rewrite" rules used by the reader, so > you could say that the "f:" prefix maps to "formi-" and then a > symbol like "f:dable" is read as "formi-dable"? I haven't been monitoring "the effort", so I can't tell much about it, but I did initially had thought of doing my own name-mangling. Since the framework has a luxury of user pressing on a "run" button to run the workbook, I actually eval the buffer myself, so I can rewrite declarations myself before I hand them to Emacs for eval. However, the debugger would see rewritten names. I don't wish that. Also there is effort of writing pre-processor/compiler whatever, which I am not sure I wish to invest in. If there was some mechanism to tell Emacs that symbol is buffer local, it would come out for free so to say. I was looking a bit in eval.c and lread.c how bvl work, but I don't understand it enough so I could hack myself this, so that is why I asked. Since there is already a way to switch between obarrays, I thought it might have been an easier route. But any way to tell Emacs that a symbol is buffer local, and eval respecting this, would work.