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: Fri, 08 May 2020 17:00:01 -0700 Message-ID: <87368a2d1a.fsf@t510.orion.oneofus.la> References: <87ftcee7td.fsf@tromey.com> <87pnbgzdmx.fsf@tromey.com> <1225997b-648a-068d-7f6b-e1575477a0d0@dancol.org> <875zd62qy7.fsf@t510.orion.oneofus.la> <09ed390e-c735-3a7e-ecfd-504557b192a2@dancol.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="56176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.3.10; emacs 26.2 Cc: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Tom Tromey , Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 02:13: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 1jXD7U-000EQ1-Ig for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 02:13:32 +0200 Original-Received: from localhost ([::1]:38596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXD7T-0001OP-J1 for ged-emacs-devel@m.gmane-mx.org; Fri, 08 May 2020 20:13:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXD6y-0000xm-6H for emacs-devel@gnu.org; Fri, 08 May 2020 20:13:00 -0400 Original-Received: from forward101j.mail.yandex.net ([5.45.198.241]:54615) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXD6v-0002ow-Vs for emacs-devel@gnu.org; Fri, 08 May 2020 20:12:59 -0400 Original-Received: from mxback25g.mail.yandex.net (mxback25g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:326]) by forward101j.mail.yandex.net (Yandex) with ESMTP id 4C9CB1BE13F9; Sat, 9 May 2020 03:12:53 +0300 (MSK) Original-Received: from sas1-26681efc71ef.qloud-c.yandex.net (sas1-26681efc71ef.qloud-c.yandex.net [2a02:6b8:c08:37a4:0:640:2668:1efc]) by mxback25g.mail.yandex.net (mxback/Yandex) with ESMTP id 9dc7ZVapQv-CqJe3886; Sat, 09 May 2020 03:12:53 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneofus.la; s=mail; t=1588983173; bh=tF6/ag7Us6e4p2i3JWlsyoBtyHmtx8pTFq6bYnJwlAk=; h=In-reply-to:Subject:Cc:To:From:Date:References:Message-ID; b=IaA0BcdMweiRptLOk0asHyN+CAl4as47GXz10J88hDS20FAWQntP7qjj51wCd3SGu 9dAGnAjjrwNp09zMZwAKZ/1Tnd+mvzhqp66HMr/6OnJqGw01dCkwRN4FaRCXlUE1GN hUYeAWmkyz7xEtG7tFc/NbrnajDK+IMM04jNamnQ= Authentication-Results: mxback25g.mail.yandex.net; dkim=pass header.i=@oneofus.la Original-Received: by sas1-26681efc71ef.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id gLE1B75PlV-CoTOXFGh; Sat, 09 May 2020 03:12:51 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-reply-to: <09ed390e-c735-3a7e-ecfd-504557b192a2@dancol.org> Received-SPF: pass client-ip=5.45.198.241; envelope-from=vas@oneofus.la; helo=forward101j.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/08 20:12:53 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, RCVD_IN_MSPIKE_H2=-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:249342 Archived-At: Daniel Colascione writes: > I wouldn't call package-local nicknames "throw[ing] away" the > namespace system. The post describes a logical extension. Is your > argument that the CL namespace system (suitably extended) *allows* > people to do silly things (like :use) even though it doesn't require > that they do? Yes, it is silly, and people do it. They will do it in Elisp if you let them. I think unintended re-definition of short names due to "namespace multiple inheritance" is going to be a problem for Elisp, because ordinary Emacs users load code from MELPA. It is a lot different than encountering the problem in C++ or something when you are a distribution maintainer compiling binaries. Neither the R6RS approach of throwing an error, nor clobbering the definition and showing a warning (what some Common Lisp implementations do) that will not be paid attention to is appropriate for what should be a backwards-compatible package update. > Fair enough. What about requiring that a colon separate the module > prefix from the remainder of the symbol? Good question. I think if you leave it open-ended, that can solve the "s.el prefix is short and bad, but we don't want people to have to change too much code" problem. Ideally all they would need to do is: --8<---------------cut here---------------start------------->8--- (declare-namespace legacy-library (use elisp29) (import modern-string s-)) --8<---------------cut here---------------end--------------->8--- > Using a dash seems ripe for misinterpretation, but someone reading > a symbol containing colon (in a way that looks vaguely reminiscent > of CL) would know to look for a namespace alias instead of > searching in vain for some global definition of st-foo or sy-foo. That is true. If you use a dash for legacy code, and suggest the use of semicolon for new code as a convention, that will help minimize the confusion. I cannot think of a better way. -- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la