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 23:37:05 +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="54631"; 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 Wed May 06 01:38:13 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 1jW78e-000E6a-P2 for ged-emacs-devel@m.gmane-mx.org; Wed, 06 May 2020 01:38:12 +0200 Original-Received: from localhost ([::1]:50428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jW78d-0007OD-RC for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 19:38:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jW783-0006yc-HA for emacs-devel@gnu.org; Tue, 05 May 2020 19:37:35 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:49164) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jW781-0000Dl-MG for emacs-devel@gnu.org; Tue, 05 May 2020 19:37:35 -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 045Nb5op018325 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 5 May 2020 23:37:05 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 045Nb5Jc009702; Tue, 5 May 2020 23:37:05 GMT In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Tue, 5 May 2020 22:20:17 +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 19:37:30 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:249060 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Tue, May 5, 2020 at 3:27 PM Andrea Corallo wrote: >> Yes is how this is worked around that in CL. It works, I'm just saying >> is error prone and unnecessary complex. > > What is complex? Understanding how quoting works? > Replacing the quote with a colon? It is complex what I've explained in the mail with the example, that is keeping track of every execution paths that can lead to a symbol being leaked. The fix is obviously trivial as was (on purpose) the example. BTW I don't think the number of characters of a fix tells much about it. After that would come all the topic of read-time side effects but is a different one and IMO [2] does a good job on that. >> No, I'm thinking to one namespace only for symbols *not* for bindings. >> This is not CL or Elisp either. > > I don't understand, I admit. I thought this conversation was about > you telling me why a reader-based system is a bad idea. What can I say, I tried to give my opinions, but if you are not satisfied with them I just apologize. You have probably over estimated me. > (It seems Tom and Stefan have explained that to a point BTW, > it's that internal Emacs features rely on certain names being > interned in the main package. Not necessarily a big problem > IMO, we can discuss that if you want.) > >> Thanks for telling me I could learn it. I'm trying to say that I think >> is unnecessary complex being too low level and that there could be >> another way. But okay if you prefer I just haven't learned how it >> works. > > It's that you insist it should do A when you ask it to do B. > It's like expecting printf("Hello World") to print "Goodbye". _If_ you allow, I can still think would be more convenient doing A even if Hyperspec says must do B. But if you like examples: You know petrol cars, there is no reason to have electric ones. If you read the manual is explained you need to put petrol into them. We can then just suggest any proponent of electric cars to just read the manual of petrol ones to understand how they works. > [1] https://zenodo.org/record/2648195 > [2] http://www.flownet.com/gat/locales.pdf > > > Also, in [1] in its section "Problems with CL packages", a very short > section in a very short paper, starts off by admitting that it's > "CL packages are a misunderstood part of CL" [1, p2]. Sounds > familiar, indeed. I must say this is one the points where your writing sounds is a bit arrogant. I'm possibly wrong but I've to say I don't enjoy this approach and the resulting tone of the conversation. I don't think it serves your points. > Then, the main criticism it levels against them is read-time > side-effects, and points to [2] for justification. We check it out. > [2] show us the unintentional interning of a symbols in the REPL > caused an typo and an unusual way to :USE packages. Forgets > to mention a REPL is interactive, by definition and that most Lisps > will contain restarts that explain the error and allow you to choose > a solution and continue cleanly after the error. The author also > presents the package version in an unnecessarily verbose way. > Finally that author admits, at the end of the section [2, page 4] > that "This is a matter of taste." De Gustibus Non Est Disputandum. Yes he's trying to show his point of view, that is the system can be confusing non convenient and error prone, for reasons he's convinced are valid and he's exposing. Obviously trying to prove that he is doing on purpose errors, because every programming language used with no errors just works. But here he's *not* trying to prove CL does not work. > Not exactly categorical, i would say. > > So you could have just said "it's not my taste". Papers just reflect the vision of the authors, this is how it works. These are not papers describing scientific experiments. Anyway I don't think we are progressing much so I suggest we just cope with our disagreement. Andrea --=20 akrl@sdf.org