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, 9 May 2020 17:12:14 -0700 Message-ID: References: <87wo5k1ycq.fsf@t510.orion.oneofus.la> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="6968"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Andrea Corallo , emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Vladimir Sedach Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 02:14:33 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 1jXZc1-0001h2-11 for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 02:14:33 +0200 Original-Received: from localhost ([::1]:36792 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXZbz-0002Jj-Oz for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 20:14:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55304) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXZZw-0001Ub-BU for emacs-devel@gnu.org; Sat, 09 May 2020 20:12:24 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36382) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXZZu-0001wm-Ny for emacs-devel@gnu.org; Sat, 09 May 2020 20:12:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=w/2fXvHuyf/txNYGQM8My/Rlum3iRJGDAutEFrc8e/Y=; b=D8R1gn6sbIJcWCOItDJeVRuIdx 0gsSnvsZwPdn9Ww9ax92T3KTy+wX8iW5SbpyqmjcXO/f12Ly/DNkNQa1H/TCcXUQqfyvZTrWjEIpM BBxG+MAKyEQfwzO+dDhl1cq5o3qIuYs2OF1K1LOwIpSWxTv9dSnrZfdLZbk+F/XgBIeKKaiVFyzqu WrgEAJFXzhuWHhKxm/V/WPqObTGuIaaGH+1skYLamO6z6EtsnQQfnSUXLHUsl7VYDm/4tVoz1dJHZ bpgFpk7lFviUv11cwq43Tdpp26MplydJlUeFPd4mBDu075N2k7rfomP/F4iNzIxv4nIQpaD743OY+ Ly4wR+8A==; Original-Received: from [2604:4080:1321:9a00:3d60:5fe6:8cb4:e9e6] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jXZZn-0000bC-Kt; Sat, 09 May 2020 17:12:15 -0700 In-Reply-To: Content-Language: en-US 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:249608 Archived-At: On 5/9/20 4:53 PM, João Távora wrote: > On Sun, May 10, 2020 at 12:30 AM Vladimir Sedach wrote: > >> The original motivation for the currently ongoing discussion (as I >> understand it) is João's attempt to solve the problem of s.el >> choosing a short prefix, without requiring all of the packages that >> rely on s.el to change the way that they call s.el > > Indeed, that is the most desired feature because there is a large > body of programs that use s.el, f.el dash.el and such. We don't want > the importation of one of those systems to pollute the namespace. > Every system we idealize, whatever the approach, should keep > its eyes on this prize, IMO. > > I've personally come up with this in > https://github.com/joaotavora/elisp-shorthand > so you can add it to the 7 or so I've counted so far. > > Vlamidir, earlier you had many questions about the shorthand > approach that I couldn't answer. shorthand.el is less than 50 loc, > it's reasonably easy to read. It's very dumb, and doesn't do > any fancy stuff, but it does solve the problem. Obviously, a proper > implementation wouldn't use advice, but proper interfaces. Another problem with prefix-less imports is the semantic confusion. Lots of symbols are named such that their function is clear only in context of the package to which they belong. For example, tramp has tramp-syntax-values, tramp-prefix-format-alist, tramp-prefix-regexp, and tramp-error. Importing these symbols as just syntax-values, prefix-format-alist, prefix-regexp, and error and using them without further qualification would probably lead to confusion at reference sites. "Uh... prefix-regexp? Prefix of what? Where? Huh?" If these symbols were instead imported as t:syntax-values, t:prefix-format-alist, t:prefix-regexp, and t:error, reference sites would be almost as clear as they are now (because the reader would ask himself "what does t: stand for?") while being much more terse.