emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A prototype for a binding based approach to proper namespaces


From: Daniel Colascione
Subject: Re: A prototype for a binding based approach to proper namespaces
Date: Sat, 9 May 2020 17:12:14 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 5/9/20 4:53 PM, João Távora wrote:
On Sun, May 10, 2020 at 12:30 AM Vladimir Sedach <address@hidden> wrote:

The original motivation for the currently ongoing discussion (as I
understand it) is João's attempt to solve the problem of s.el
choosing a short prefix, without requiring all of the packages that
rely on s.el to change the way that they call s.el

Indeed, that is the most desired feature because there is a large
body of programs that use s.el, f.el dash.el and such. We don't want
the importation of one of those systems to pollute the namespace.
Every system we idealize, whatever the approach, should keep
its eyes on this prize, IMO.

I've personally come up with this in
https://github.com/joaotavora/elisp-shorthand
so you can add it to the 7 or so I've counted so far.

Vlamidir, earlier you had many questions about the shorthand
approach that I couldn't answer.  shorthand.el is less than 50 loc,
it's reasonably easy to read.  It's very dumb, and doesn't do
any fancy stuff, but it does solve the problem.  Obviously, a proper
implementation wouldn't use advice, but proper interfaces.

Another problem with prefix-less imports is the semantic confusion. Lots of symbols are named such that their function is clear only in context of the package to which they belong. For example, tramp has tramp-syntax-values, tramp-prefix-format-alist, tramp-prefix-regexp, and tramp-error. Importing these symbols as just syntax-values, prefix-format-alist, prefix-regexp, and error and using them without further qualification would probably lead to confusion at reference sites. "Uh... prefix-regexp? Prefix of what? Where? Huh?"

If these symbols were instead imported as t:syntax-values, t:prefix-format-alist, t:prefix-regexp, and t:error, reference sites would be almost as clear as they are now (because the reader would ask himself "what does t: stand for?") while being much more terse.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]