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

[Daniel Colascione <dancol@dancol.org>]

On 5/9/20 4:53 PM, João Távora wrote:
> On Sun, May 10, 2020 at 12:30 AM Vladimir Sedach <vas@oneofus.la> 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.