Re: Proper namespaces in Elisp

[Vladimir Sedach]

João Távora <address@hidden> 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