From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: A prototype for a binding based approach to proper namespaces Date: Sat, 09 May 2020 08:16:17 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="43657"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.24.0-1585 (build: 102400006) Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 17:18:26 2020 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 1jXRFC-000BGj-6Y for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 17:18:26 +0200 Original-Received: from localhost ([::1]:58414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXRFA-0001jW-KQ for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 11:18:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXRDD-0000UT-Vb for emacs-devel@gnu.org; Sat, 09 May 2020 11:16:23 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:56088) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXRDC-0001Nd-Ku for emacs-devel@gnu.org; Sat, 09 May 2020 11:16:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version: Subject:References:In-Reply-To:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cNRyFtUIsWv71/FozdF7YmlPbEMg5IiM8ZLpE4hjbbA=; b=BDaeiwuT2eCyhUOI92zLwLPpZx 42/vJKRRpessUs6G/TGHBOwE5OjLUCc49hjuypz1Wfi8Zkpr6LxkSQSpVZodvycgU2lDVoygultya pPtvR6SJaWwy+G6BIOakMv8l6uSfCr2NTnce5gKsi+77/ufm2gj3QzBrUpzWejdjLd+yx+oBplLaV +eLwN47upiumDAQRci/ySx6rQLbEgtHrxc95Bq2M1iSYIyJhEw8ncwXiVR6mLMfw0/k+nZkJKBioT HgNOp10cubjSter+UuMcCDS9pmH8rhdR+D2v6oVCPtNgY7R7pmZkvVqkuuOB8TNseSVfD0eo3ozig 9Q5viGRA==; Original-Received: from [172.92.145.124] (helo=[192.168.86.155]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jXRD9-0007OQ-2m; Sat, 09 May 2020 08:16:19 -0700 In-Reply-To: Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fedf:adf3; envelope-from=dancol@dancol.org; helo=dancol.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 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, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:249463 Archived-At: On May 9, 2020 1:05:27 AM Andrea Corallo wrote: > Daniel Colascione writes: > >> On May 8, 2020 1:49:05 PM Andrea Corallo wrote: >> >>> Hi all, >>> >>> given the ongoing discussion on namespaces I thought was interesting to >>> try out a prototype to reason on. >>> >>> I wrote a short page explaining what I did and how it is implemented: >>> >>> https://akrl.sdf.org/lexspaces/lexspaces.html >>> >>> It's a quick hack, certainly many pieces are missing, is potentially a >>> very bad idea, but I'd be interested in opinions. >> >> If the set of imports is known at compile time, why do we need to pay >> the runtime cost of the binding? > > I think it depends on how resilient you want to have your language to > redefinitions. Say you have four libraries B derived from A and C from > B etc: > > A <= B <= C <= We don't have these problems at all with an approach based on symbol rewriting in the reader. Even one additional pointers chase at runtime is too much, especially since we're considering using this mechanism as a routine way to access module provided facilities and not as a rare patch for papering over other problems, as with existing symbol aliases. (Thanks to modern memory architectures, each pointer chase is brutal.) Yes, I dislike reader magic, but I dislike runtime overhead a lot more. > E has visibility on ~everything was defined in A. Now what if while > running A changes the value of something used by E? We need at least > one indirection to handle that otherwise you would be pointing still to > the original object. But it is more complex because while running B > could decide to unimport the definition from A and define the variable > locally, Why should we support this kind of post definition namespace modification?