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: Proper namespaces in Elisp Date: Tue, 05 May 2020 10:33:58 +0000 Message-ID: References: <237fe643-c14d-5406-b35d-a30dcd42c5ed@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="67080"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: nic@ferrier.me.uk, =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel , emacs-devel , Stefan Monnier , Helmut Eller To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 12:35:04 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 1jVuum-000HKQ-CT for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 12:35:04 +0200 Original-Received: from localhost ([::1]:50480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVuul-00086X-EW for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 06:35:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34762) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVuuD-0007cv-Gw for emacs-devel@gnu.org; Tue, 05 May 2020 06:34:29 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:60158) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVuuB-0006AJ-90 for emacs-devel@gnu.org; Tue, 05 May 2020 06:34:29 -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 045AXwTD010762 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 5 May 2020 10:33:58 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 045AXwTw017396; Tue, 5 May 2020 10:33:58 GMT In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Mon, 4 May 2020 23:34:06 +0100") 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/05 06:34:19 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:248964 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Mon, May 4, 2020 at 10:59 PM Andrea Corallo wrote: >> >> Jo=C3=A3o T=C3=A1vora writes: >> >> > On Mon, May 4, 2020 at 7:30 PM Helmut Eller w= rote: >> >> should be done by the compiler (like lexical scoping). In other word= s, >> >> those people would like a mechanism to manage the names of variable >> >> bindings not a mechanism to manage symbols. >> > >> > That last sentence sounds clever but I can't fully grok it. Do you >> > really mean "variable bindings" or just "bindings"? (including functio= n's). >> > >> > On Mon, May 4, 2020 at 7:39 PM Stefan Monnier wrote: >> >> Richard mentioned his profound dislike of solutions that operate in >> >> the reader. I'm not sufficiently familiar with Common Lisp's package >> >> system to have a strong opinion on that, but Richard's criticism does >> >> appeal to me (I've been brought up on namespace systems more like >> >> Standard ML's structures). >> > >> > I can't even imagine what a solution that _doesn't_ operate on the rea= der >> > looks like. Are you talking about form walking macros that walk the >> > forms and switch the short version of names into the long versions >> > and intern everything into the same obarray? Hmmm. >> >> Namespaces in the read time is a bad idea because it does not affect >> only bindings but effectively all symbols. I, as many others, do not >> like CL package system too for this reason and all its implications. > > Well, let's have "all its implications" then. Because you've done > nothing more than describe in simplified fashion what it does, > and that's not an argument to support the contention that > "it is a bad idea". Here is a first simple implication of namespace at read-time: #+SRC_BEGIN lisp (make-package :xxx) (in-package :xxx) (defun foo () 'aaa) (export 'foo) (make-package :yyy) (in-package :yyy) (use-package :xxx) (if (not (eq (foo) 'aaa)) (print "boom")) #+END_BEGIN This is because foo is not returnig 'aaa' but 'xxx::aaa'. It will be told that you have to export also 'aaa' from the package xxx because "leaking symbols" is bad. But in reality this implies you have to identify all execution paths that can leak a symbol and remember to export these syms otherwise you'll get subtle bugs for any symbol leaked passed in any kind of object. Sure can be done (it is done) and we all got used to that but is just a source of bugs due to bad design, not a feature. One should import from a package *bindings* not symbols. Unfortunatelly the implementation can't distinguish those at read time because those do not exists already. With all the goodies of CL packages are really not the best example to look at :) > >> I think Emacs has most of the infrastructure to implement this already >> in the codebase but right now I've not time to work on a prototype ( > > I too think a dumb man's namespacing can be implemented, > just to alleviate this alias-all-the-functions pressure. Did you > read my shorthand idea, I think it could fly. I don't think the soulution should be dumb, and I think we should aim for the correct solution if we decide to go for it. IMO a good part of the code is already present to support this but as usual the bring-up would be considerably slower that the original optimistic expectation. That said without a prototype all of this is just blablabla :) Andrea --=20 akrl@sdf.org