From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Vladimir Sedach Newsgroups: gmane.emacs.devel Subject: Re: Proper namespaces in Elisp Date: Wed, 06 May 2020 15:47:48 -0700 Message-ID: <87eerwznmz.fsf@t510.orion.oneofus.la> References: <237fe643-c14d-5406-b35d-a30dcd42c5ed@gmail.com> <87v9lb1irk.fsf@t510.orion.oneofus.la> <87sggf193f.fsf@t510.orion.oneofus.la> <87k11q1ghn.fsf@t510.orion.oneofus.la> <87k11pzqw7.fsf@t510.orion.oneofus.la> 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="39017"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.3.10; emacs 26.2 Cc: emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 07 02:54:10 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 1jWUni-000A0V-5S for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 02:54:10 +0200 Original-Received: from localhost ([::1]:52770 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWUnh-0007pP-61 for ged-emacs-devel@m.gmane-mx.org; Wed, 06 May 2020 20:54:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWUmW-0006DJ-Rj for emacs-devel@gnu.org; Wed, 06 May 2020 20:52:56 -0400 Original-Received: from forward100o.mail.yandex.net ([37.140.190.180]:38204) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWUmU-0001ng-5A for emacs-devel@gnu.org; Wed, 06 May 2020 20:52:56 -0400 Original-Received: from mxback27o.mail.yandex.net (mxback27o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::78]) by forward100o.mail.yandex.net (Yandex) with ESMTP id BD12D4AC1F05; Thu, 7 May 2020 03:52:49 +0300 (MSK) Original-Received: from myt5-95c1fb78270f.qloud-c.yandex.net (myt5-95c1fb78270f.qloud-c.yandex.net [2a02:6b8:c12:1725:0:640:95c1:fb78]) by mxback27o.mail.yandex.net (mxback/Yandex) with ESMTP id bJH8YqNDwH-qn8SSLsa; Thu, 07 May 2020 03:52:49 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneofus.la; s=mail; t=1588812769; bh=3JZtvGqvVa6g/VWkG7bhsHZdPcVNGOaWPfNB/O0dJ/8=; h=In-reply-to:Subject:Cc:To:From:Date:References:Message-ID; b=DBJdwTWfNQd8x7vv4h96fM+HrabaAoXt1YOwDWJNGHiBSSnNkskh3iatdIPM8V+G9 8+QX/FSykH9mo9RNh8S1xMb4uJdF/6Oc+tjkn7aJDPGAWFKpBqR0KyVZm5h+3sn956 cb9YI6i0k6jfj+w1nB1z1mkwZ7qn6HJ92Z2HIXn4= Authentication-Results: mxback27o.mail.yandex.net; dkim=pass header.i=@oneofus.la Original-Received: by myt5-95c1fb78270f.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id rCm7mG99yR-qm2064bF; Thu, 07 May 2020 03:52:48 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-reply-to: Received-SPF: pass client-ip=37.140.190.180; envelope-from=vas@oneofus.la; helo=forward100o.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/06 20:52:50 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_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:249134 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Wed, May 6, 2020 at 4:38 AM Vladimir Sedach wrote: > Let me start with a fact from another non-Lisp language. If in > C++ (where you people that have the the very same > misunderstanding BTW) you abuse the "using" directive correctly > you run into the the very same situation. "C++ does it wrong" is not an argument for anything. C++ does whole-program static compilation, and users of C++ programs do not have the need to load and re-define code at run-time, and do not regularly pull updates for libraries from MELPA. Since Scheme is also mostly used for whole-program static compilation, the R6RS approach is appropriate there. Elisp is not used that way. > Yes, and because she decided to use :USE for a package that is > outside her control, she is obligated to register somewhere that her > library only supports <=3D1.0. It's very simple. It's not related to > CL at all. Trying to solve this as a dependency management problem is not going to work. > Where, pray tell, is this Village of Dubious Recommendations? :-) I first learned about this in ircs://chat.freenode.net/#lisp from the many experienced Common Lisp programmers there. > So it errors when symbols clash? When they clash, and when you try to re-define an exported symbol: --8<---------------cut here---------------start------------->8--- Chez Scheme Version 9.5 Copyright 1984-2017 Cisco Systems, Inc. > (library (ABC) (export FOO) (import (rnrs)) (define FOO 111)) > (library (XYZ) (export) (import (rnrs) (ABC)) (define FOO 222)) Exception: multiple definitions for FOO in body (library (XYZ) (export) (im= port (rnrs) (ABC)) (define FOO 222)) Type (debug) to enter the debugger. > (library (XYZ) (export) (import (rnrs) (ABC))) > (import (ABC)) > (set! FOO 222) Exception: attempt to assign immutable variable FOO Type (debug) to enter the debugger. > --8<---------------cut here---------------end--------------->8--- > A possible strategy, I guess, but not really a "solution" because > the problem has no solution. There are many different solutions, some better than others. > Fine. Let's get one with local nicknames and you'll use only that. That is one possible solution I had not even thought of. Relevant reading: https://gist.github.com/phoe/2b63f33a2a4727a437403eceb7a6b4a3 In Andrea's scheme (which I am in favor of), one possible solution would be assign a new binding in the local namespace when an imported symbol is re-defined. I think this could work for dynamic scoping if you use the binding instead of the symbol for the lookup, but I have not thought the problem fully through yet. Then, when you really want to re-define something in another package, you can use something like the Guile @ and @@ module access special forms (@ is for exported symbols, @@ for internal; see section 6.20.2 Using Guile Modules of the Guile manual): (set! (@ (GNUS ABC) FOO) 456) There are two things to note from the above: 1. The Common Lisp PACKAGE:SYMBOL syntax is infix in disguise. As I noted previously, it also complicates printing and reading s-expressions. The Guile approach does not have this problem and does not need changes to the reader. 2. The Scheme convention of naming namespaces with a list of symbols is a good way to organize namespace, and avoids the complications of hierarchical namespace systems and the problem of trying to express structure in a string or symbol name. The Scheme approach would be very inconvenient when in an IELM REPL or *scratch* buffer (it is annoying enough in Scheme), and it is not going to work for M-x execute-extended-command. How namespacing is going to work with commands is another important consideration that has not been brought up. >> If you don't believe me, you can ask in >> ircs://chat.freenode.net/#lisp > > What should I ask? "has anyone here ever misused the package > system? or written bad code"? Doesn't sound very interesting. And > if those people have something to add, they can do it here, no? You can ask other experienced Common Lisp programmers about defining packages and the pitfalls of :use. A lot of people there have strong opinions and useful recommendations. -- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la