From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: A prototype for a binding based approach to proper namespaces Date: Sat, 09 May 2020 10:57:53 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="9934"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 12:58:34 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 1jXNBh-0002TQ-Pv for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 12:58:33 +0200 Original-Received: from localhost ([::1]:44346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXNBg-0006a9-Sr for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 06:58:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47860) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXNB8-0005Sv-Ur for emacs-devel@gnu.org; Sat, 09 May 2020 06:57:58 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:60201) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXNB7-0004sV-FP for emacs-devel@gnu.org; Sat, 09 May 2020 06:57:58 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 049AvsYR018513 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 9 May 2020 10:57:54 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 049AvrvV017696; Sat, 9 May 2020 10:57:53 GMT In-Reply-To: (Helmut Eller's message of "Sat, 09 May 2020 10:50:40 +0200") Received-SPF: pass client-ip=205.166.94.20; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/09 06:57:54 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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:249397 Archived-At: Helmut Eller writes: > I'm not sure that I understand you. > > Just do make my point clear(er): functions that accept symbols > (e.g. face-name) don't know anything about the current lexical > environments of the caller. symbol-function is one of them. The only > sensible place where symbol-function could search is the global > environment. > > Helmut I start to see the issue. If two libraries are using a symbol to communicate something shouldn't the definition of this something be imported by both? Say faces are defined in the 'face' Lexspace, the two libraries should probably derive from it if they want to communicate using this definitions. There are maybe cases where the 'resolve-designator' operator you have suggested would be necessary but I don't know how common would be that case. Andrea PS I think practically faces would be in the fundamental Lexspace where every other is derived from. -- akrl@sdf.org