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: Thu, 07 May 2020 19:56:05 -0700 Message-ID: <87d07f2kze.fsf@t510.orion.oneofus.la> References: <87ftcee7td.fsf@tromey.com> <87pnbgzdmx.fsf@tromey.com> <87lfm3290o.fsf@tromey.com> <87ftcb37jx.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="126269"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.3.10; emacs 26.2 Cc: Tom Tromey , Stefan Monnier , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 08 05:11:08 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 1jWtPn-000Wl4-MO for ged-emacs-devel@m.gmane-mx.org; Fri, 08 May 2020 05:11:07 +0200 Original-Received: from localhost ([::1]:48154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWtPm-0002UD-Of for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 23:11:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53926) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWtPI-000230-9e for emacs-devel@gnu.org; Thu, 07 May 2020 23:10:36 -0400 Original-Received: from forward101o.mail.yandex.net ([2a02:6b8:0:1a2d::601]:42655) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWtPG-0001jk-A8 for emacs-devel@gnu.org; Thu, 07 May 2020 23:10:35 -0400 Original-Received: from forward100q.mail.yandex.net (forward100q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb97]) by forward101o.mail.yandex.net (Yandex) with ESMTP id C05173C02428; Fri, 8 May 2020 06:10:27 +0300 (MSK) Original-Received: from mxback8q.mail.yandex.net (mxback8q.mail.yandex.net [IPv6:2a02:6b8:c0e:42:0:640:b38f:32ec]) by forward100q.mail.yandex.net (Yandex) with ESMTP id BC97F708000B; Fri, 8 May 2020 06:10:27 +0300 (MSK) Original-Received: from vla5-445dc1c4c112.qloud-c.yandex.net (vla5-445dc1c4c112.qloud-c.yandex.net [2a02:6b8:c18:3609:0:640:445d:c1c4]) by mxback8q.mail.yandex.net (mxback/Yandex) with ESMTP id K1jXvMXOuY-ARs0hIC2; Fri, 08 May 2020 06:10:27 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneofus.la; s=mail; t=1588907427; bh=3me5lHMdcDRYj8zbkKUUmlVB/mu5SDbdVoPXCpl1Wtw=; h=In-reply-to:Subject:Cc:To:From:Date:References:Message-ID; b=l9+sBmqPgPK0shYeWmzODhVf7O6Avy9Jlx+g7ElQCOXijtXJIFpzoyYnm/ceciFpd uT8Ofr2LCBKHUZjmAbmNVMXie24ES58u7oJlCk0zqgVeLr1HnQ0mjIlReD7KrLSD9o iu6xBQA8QrzMU2ihku7YYRpzjhonPkx9D9BjujnQ= Authentication-Results: mxback8q.mail.yandex.net; dkim=pass header.i=@oneofus.la Original-Received: by vla5-445dc1c4c112.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id oQcysn7BWa-APWaRcH1; Fri, 08 May 2020 06:10:26 +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=2a02:6b8:0:1a2d::601; envelope-from=vas@oneofus.la; helo=forward101o.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, 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:249237 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > All namespacing in all languages systems "break" grep if > you give grep a volatile namespace qualifier. This just comes > with the namespacing. That is not true. A reference like NAMESPACE:SYMBOL makes it obvious that you should search for SYMBOL. This is why GNU etags works for Common Lisp, without understanding Common Lisp packages. Because an explicit namespace separator like : is in most cases unambiguous and easy to parse, it is also possible to write tools that understand it. The proposed system has arbitrary prefixes. How do you know what to search for? > And in your solution the problem then becomes teaches isearch, > query-replace and its various variants, a (probably very large) > number of tools in the wild about this these overlays. You see > "yalp-" then C-s yalp- and find nothing!. Another medium-size > annoyance would be alignment and keeping to column limits, > like the ones Emacs has. That is true. I am not advocating for overlays/abbrev. I am pointing out that it gets you a lot of the same benefits as the proposed system, while being far less intrusive. As I pointed out in the other sub-thread, a namespace system that does the wrong thing is a lot worse than the current status quo of not having a namespace system at all. Why not come up with something that works well, instead of relying on magic comment reader hacks? You could get a lot of auxiliary benefits out of a good solution as well (for example, real namespace declarations such as CL defpackage/R6RS library will let you generate autoloads automatically for exported symbols). A question related to isearch: how would the proposed system work with apropos? > But most crucially: All this started because there are a zillion > packages in the wild using s.el. They all invoke its functions > with "s-foo". You would ALL need to be massively and > intrusively changed and the authors convinced to use your system > instead. With my system we can mostly (if not entirely) keep their > code untouched, so these files that (require 's) will not know they > are actually working with modern-string.el instead of s.el. I am sorry, I don't follow. The proposal is for a file-local setting that requires magic comments. Why wouldn't package authors be required to change their code to use this? Or are you saying that this: ;;; Shorthand: (("vl-" . "very-long-prefix-") ;;; ("yalp-" . "yet-another-long-prefix-")) Goes in the file defining the namespace, and everything read after that turns yalp-foo into yet-another-long-prefix-foo? Wouldn't that affect completely unrelated code that happens to mention yalp-bar somewhere (like throw tags)? -- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la