Re: Emacs Lisp's future

[Elias Mårtenson]

On 11 October 2016 at 23:10, Clément Pit--Claudel <address@hidden> wrote:

On 2016-10-11 10:54, Elias Mårtenson wrote:

 

> All of these tools have the problem that it's difficult to tell what
> part of a symbol is its "namespace". How do you tell the difference
> between the symbols "foo-bar" without a namespace, or "bar" with
> namespace "foo"?

Indeed.  Have you had this problem in practice, though?

That depends on how you define "having the problem". I don't use automated tools (such as nameless) partly because I find it somewhat hackish. I have been confused about it though.

 

It's generally sufficient to look at the name of the file that declares that function.  For example, gnu-apl-interactive-mode presumably lives in gnu-apl.el.  If not, then you can set a file-local variable indicating what the library's prefix is.

It actually lives in a file called gnu-apl-interactive.el.

 

> I guess I'm just curious as to why a separate symbol isn't used? :
> sounds good, and gnu-apl:interactive-mode would be much more clear.
> Automated tools would also be able to make more sense out of symbol
> names.

nameless uses ':' for display (and '::' for private members), indeed.  Some packages use / (yas/, for example)

Presumably they do this because they agree with me that overloading the use of the - character for both word separation and namespace indicator is not optimal. The use of multiple different variations is even worse (which is why I, even though I don't agree with the practice of using - and --, conform to it).

I'm merely trying to put the attention on this, to gauge just how many people agree with me. I suspect that not enough does.

I still want to summarise what I'd like to see: Use : (or some other character other than -) to separate namespace and name. Use :: (or something else) to indicate private symbols. Then, standardised tooling in Emacs that would handle this convention could come later (as in something like nameless, or perhaps an extension to the reader to handle it).

In other words: I think that as long as the character overloading problem is fixed and a standardised method is promoted, creating tools that implement pretty much everything people want from a namespace/package system can be implemented on top of this convention.

Elias