Namespaces - summary, conclusion

Namespaces - summary, conclusion

[Philippe Vaucher]

Hello,

I think for my part the amount of bikeshedding done was enough now and
I can come to some conclusions.

The proposal of aliasing or renaming Elisp functions that some of us
feel inadequately named/grouped got mostly a strong resistance by what
can be considered iconic figures of this community. I think that
cannot be taken lightly.

Here's a non exhaustive list of the counter-arguments, roughly ordered
how I feel are the best arguments to the not-so-relevant but
interesting:

- Adding new aliases, while improving the experience of those who like
to do an exact search for the regexp "^domain-.*", will degrade the
experience of those who like to search the manual "the classic way"
using "C-h d" or "C-h a".
- Adding new aliases or renaming functions might confuse the users
that are used to the current names. For example they might not
immediately understand that "re-search-in-string" means "string-match"
and have to look it up, wasting time.
- Adding new aliases increases the memory usage, the size of the
manual, and the amount of things to maintain.
- Emacs Lisp is fundamentaly a language where all concepts intermix
and thus is chaotic by nature, trying to organize it into categories
is against history and does not make sense.
- Even if we agree not to even touch the function name other than
adding a prefix (e.g `keep-lines` becoming `buffer-keep-lines`),
people will disagree on which prefix to use or about the genericity of
a function making it unprefixable, or that's it's a crime to history,
and thus consensus will be impossible to attain for almost every
proposed function.

Given this is more or less the position held by Alan, Eli, Richard,
Drew and João I think the chances of seeing new aliases is close to 0.
Until now every one of the proposed aliases (in string- or regexp-)
were rejected for arguably good reasons but the message is pretty
clear, I think aliases in Emacs core are a dead end (for now, that
might change later) and will only live in libraries in MELPA (or ELPA
is authors care).

So, the altenatives proposed are, ordered by chances of seeing it happening:

- Not rename anything, write some completion function that first
completing-read one of the section at
https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html,
then using tricks to collect all function names there completing-read
that list of functions. Might be bound to a new "C-h <somekey>".
- Improve the sorting algorithm so somehow the function names
associated with a topic are automatically but to the top when you
search one of the "obvious" keywords like "alist" or "regexp". The
path toward that solution is pretty unclear to me, feel free to expand
on it.
- Add namespaces to Emacs Lisp.

Then there are other discussions going on, like the manual not
offering a "tutorial view" with highlighted examples, but I think
these are other discussions and should be discussed on their own.

Kind regards,
Philippe

Re: Namespaces - summary, conclusion

[Philippe Vaucher]

> Then there are other discussions going on, like the manual not
> offering a "tutorial view" with highlighted examples, but I think
> these are other discussions and should be discussed on their own.

I also forgot to talk about another topic: the inclusion of new
functions, like the ones from s.el that do not exist yet in Emacs.

The community looks more open about this, but so far many of my
proposals were said to already exist under another name or people
didn't understand what the functions did. We'll also continue this
discussion in another thread.

Philippe

Re: Namespaces - summary, conclusion

[Stefan Kangas]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

> Given this is more or less the position held by Alan, Eli, Richard,
> Drew and João I think the chances of seeing new aliases is close to 0.

This is not my conclusion.  I've seen several calls to move away from
from discussing in the abstract to discuss specific, concrete
examples.  I think this is a good idea, since IMHO the abstract
discussion is likely exhausted.

There is always the chance that some of the proposals will be voted
down.  But also consider that some who have disagreed with you in the
abstract might be more convinced by specific, concrete proposals.

> Then there are other discussions going on, like the manual not
> offering a "tutorial view" with highlighted examples, but I think
> these are other discussions and should be discussed on their own.

I think here also concrete proposals would help us move forward.

Best regards,
Stefan Kangas

Re: Namespaces - summary, conclusion

[Philippe Vaucher]

> > Given this is more or less the position held by Alan, Eli, Richard,
> > Drew and João I think the chances of seeing new aliases is close to 0.
>
> This is not my conclusion.  I've seen several calls to move away from
> from discussing in the abstract to discuss specific, concrete
> examples.  I think this is a good idea, since IMHO the abstract
> discussion is likely exhausted.
>
> There is always the chance that some of the proposals will be voted
> down.  But also consider that some who have disagreed with you in the
> abstract might be more convinced by specific, concrete proposals.

So far the string- proposal got shot down entirely. The regexp one was
initially a no-go from Alan but I then Richard kinda liked it and
proposed adaptations.

@Stefan Monnier: I see that you talked about `multibyte-string-p`
already (and iirc that didn't went well. You talked earlier about
`process-`, maybe you'd like to propose some changes there?

I mean I'm willing to propose concrete changes but if it's not obvious
for string- and regexp- why would it be for other topics? Let's try
another topic just to see:

rename-file -> file-rename
delete-file -> file-delete
copy-file -> file-copy
expand-file-name -> file-expand-name

Do you think people will be ok with that?

Philippe

Re: Namespaces - summary, conclusion

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

   > > Given this is more or less the position held by Alan, Eli, Richard,
   > > Drew and João I think the chances of seeing new aliases is close to 0.
   >
   > This is not my conclusion.  I've seen several calls to move away from
   > from discussing in the abstract to discuss specific, concrete
   > examples.  I think this is a good idea, since IMHO the abstract
   > discussion is likely exhausted.
   >
   > There is always the chance that some of the proposals will be voted
   > down.  But also consider that some who have disagreed with you in the
   > abstract might be more convinced by specific, concrete proposals.

That too is my understanding of the discussion.

   So far the string- proposal got shot down entirely. The regexp one was
   initially a no-go from Alan but I then Richard kinda liked it and
   proposed adaptations.

   @Stefan Monnier: I see that you talked about `multibyte-string-p`
   already (and iirc that didn't went well. You talked earlier about
   `process-`, maybe you'd like to propose some changes there?

Personally, I think there are way too many half proposal -- by which I
mean one suggests something to see if it is OK, but without any
reasoning towards _why_ it is a good idea -- on doing way to many
changes for a very negligible benefit.

Such overwhelming changes will most surely be shot down quickly.

   I mean I'm willing to propose concrete changes but if it's not obvious
   for string- and regexp- why would it be for other topics? Let's try
   another topic just to see:

   rename-file -> file-rename
   delete-file -> file-delete
   copy-file -> file-copy

These functions are also interactive, where it is far more natural to
want to rename/delete/copy a file, than ... a file
renamed/deleted/copied.
 
   expand-file-name -> file-expand-name

You're expanding a file name, so the name seems to fit the task.

Re: Namespaces - summary, conclusion

[Stefan Kangas]

Alfred M. Szmidt <ams@gnu.org> writes:

>    expand-file-name -> file-expand-name
>
> You're expanding a file name, so the name seems to fit the task.

Not bad, but I would prefer "file-name-expand".

Best regards,
Stefan Kangas

Re: Namespaces - summary, conclusion

[Joost Kremers]

On Mon, May 04 2020, Alfred M. Szmidt wrote:
>    rename-file -> file-rename
>    delete-file -> file-delete
>    copy-file -> file-copy
>
> These functions are also interactive, where it is far more 
> natural to
> want to rename/delete/copy a file, than ... a file
> renamed/deleted/copied.
>  
>    expand-file-name -> file-expand-name
>
> You're expanding a file name, so the name seems to fit the task.

But wouldn't that be an excellent reason to have an alias?

-- 
Joost Kremers
Life has its moments

Re: Namespaces - summary, conclusion

[Alfred M. Szmidt]

   >    rename-file -> file-rename
   >    delete-file -> file-delete
   >    copy-file -> file-copy
   >
   > These functions are also interactive, where it is far more 
   > natural to
   > want to rename/delete/copy a file, than ... a file
   > renamed/deleted/copied.
   >  
   >    expand-file-name -> file-expand-name
   >
   > You're expanding a file name, so the name seems to fit the task.

   But wouldn't that be an excellent reason to have an alias?

I think it was mentioned before, but aliases are not without a cost.
They have to be maintained, and there is the cognitive load as well.
The line to draw where one stops adding aliases becomes fuzzy quickly.

Having multiple names for the same thing also reduces discoverability,
since now you have multiple things called similar but possible
different.  And Emacs already provides excellent means to discover
things, as pointed out by Eli several times.

If Emacs was started today from scratch, some of these naming changes
would maybe be a good idea (e.g., file-name-expand
vs. expand-file-name -- neither is a bad name for that particular
function) ... but expand-file-name is as old as Emacs, and as a
function name for what it does it is adequate.

Changing/Adding such a name (or any other name) has to be weighed
against that, and that is very heavy pot of gold.  And I think Eli, et
al want something more than just a list of here are functions that
should change or what ones current preference is... 

Change for changes sake isn't very useful.  Sometimes good enough is
just perfect.

Re: Namespaces - summary, conclusion

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Mon, 4 May 2020 11:27:00 +0200
> 
> The proposal of aliasing or renaming Elisp functions that some of us
> feel inadequately named/grouped got mostly a strong resistance by what
> can be considered iconic figures of this community.
> [...]
> Given this is more or less the position held by Alan, Eli, Richard,
> Drew and João I think the chances of seeing new aliases is close to 0.

I think you jump to conclusions too quickly.  Each one of the named
individuals expressed quite different views about the
renaming/aliasing proposals.  In particular, the degree of resistance
to any and all such changes from each one of those people was very
different.  AFAIU, only Alan is completely opposed to any such change.

It should not surprise anyone that a proposal to summarily rename many
of our core APIs should not be agreed to lightly.  Show me another
project that did something like that.

That said, if we are willing to continue discussing this, we might be
able to agree to some small enough group of functions for which more
systematically-named aliases could be added.

> Until now every one of the proposed aliases (in string- or regexp-)
> were rejected for arguably good reasons but the message is pretty
> clear, I think aliases in Emacs core are a dead end (for now, that
> might change later) and will only live in libraries in MELPA (or ELPA
> is authors care).

That's not my conclusion.  I think a small number of aliases could be
agreed to, based on the responses.

I urge you not to give up.

Thanks.

Re: Namespaces - summary, conclusion

[조성빈]

Philippe Vaucher <philippe.vaucher@gmail.com> 작성:

>>> Given this is more or less the position held by Alan, Eli, Richard,
>>> Drew and João I think the chances of seeing new aliases is close to 0.
>>
>> This is not my conclusion.  I've seen several calls to move away from
>> from discussing in the abstract to discuss specific, concrete
>> examples.  I think this is a good idea, since IMHO the abstract
>> discussion is likely exhausted.
>>
>> There is always the chance that some of the proposals will be voted
>> down.  But also consider that some who have disagreed with you in the
>> abstract might be more convinced by specific, concrete proposals.
>
> So far the string- proposal got shot down entirely. The regexp one was
> initially a no-go from Alan but I then Richard kinda liked it and
> proposed adaptations.
>
> @Stefan Monnier: I see that you talked about `multibyte-string-p`
> already (and iirc that didn't went well. You talked earlier about
> `process-`, maybe you'd like to propose some changes there?

I think for people to propose changes and get them adapted, we first have to
have some proper goals to target.

So there are a few people here who think renaming some functions is  
beneficial
- but everybody’s reasoning is different here. Some people who are opposed to
renaming are a bit confused.

I think the two big goals are consistency and discoverability. And then there
are various small arguments like it’s easier to use prefix based completion  
and
function search, it’s easier to guess, namespace means less function name
clashing, etc…

I think consistency is important, and if the language itself wants naming
things the ‘lisp-way’, I’m fine with a consistent naming scheme. I’m not sure
if you’d agree or not, but maybe trying to find a consistent naming scheme  
and
documenting them (which was called as the ‘lisp-way’ by some) might be first.
And then we can rename the ones that don’t follow them.

> I mean I'm willing to propose concrete changes but if it's not obvious
> for string- and regexp- why would it be for other topics? Let's try
> another topic just to see:
>
> rename-file -> file-rename
> delete-file -> file-delete
> copy-file -> file-copy
> expand-file-name -> file-expand-name
>
> Do you think people will be ok with that?

The reason why I said about finding the naming scheme was because both the
function name rename-file and file-truename makes sense to me.

I think some preliminary conventions that Elisp already follows is that the
<action>-<object> scheme is for actions on the object like rename-file or
clear-string, and <object>-<property> scheme is for getting properties of the
object like string-width and file-name-extension. (I’m not considering
polymorphic ones.)

But then there are exceptions, like string-trim (which should then be
trim-string) or string-join (which should then be join-string).

What does everybody think about this? I think it would be less disruptive and
controversial if some Elisp core API guidelines are decided, written, and
followed in the future. Then, if it turns out it’s useful enough, we can  
start
aliasing functions that don’t follow them to names that do follow them (if
it’s desirable to do so.)

> Philippe

Re: Namespaces - summary, conclusion

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Mon, 4 May 2020 14:42:58 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> rename-file -> file-rename
> delete-file -> file-delete
> copy-file -> file-copy
> expand-file-name -> file-expand-name

These are different: in Emacs we have functions that work on _files_,
and we have functions that work on _file names_.  The first 3 above
are of the former kind, the last one is of the second kind (there are
a lot more of that kind).  We shouldn't mix them.

Re: Namespaces - summary, conclusion

[tomas]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

On Mon, May 04, 2020 at 10:18:32AM -0400, Alfred M. Szmidt wrote:

[...]

> Having multiple names for the same thing also reduces discoverability,

Even worse yet, as has been mentioned (but is often forgotten), it
makes code readability harder.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Namespaces - summary, conclusion

[Philippe Vaucher]

> I think you jump to conclusions too quickly.  Each one of the named
> individuals expressed quite different views about the
> renaming/aliasing proposals.  In particular, the degree of resistance
> to any and all such changes from each one of those people was very
> different.  AFAIU, only Alan is completely opposed to any such change.

Ah, ok I somehow inferred that Alan was the only one to say out loud
what you guys also thought, given your "resistance".


> That said, if we are willing to continue discussing this, we might be
> able to agree to some small enough group of functions for which more
> systematically-named aliases could be added.
>
> > Until now every one of the proposed aliases (in string- or regexp-)
> > were rejected for arguably good reasons but the message is pretty
> > clear, I think aliases in Emacs core are a dead end (for now, that
> > might change later) and will only live in libraries in MELPA (or ELPA
> > is authors care).
>
> That's not my conclusion.  I think a small number of aliases could be
> agreed to, based on the responses.
>
> I urge you not to give up.

Thanks. Until now I haven't seen any of the "string-" proposition
where there was the beginning of a consensus, but I'll look again. If
you have something in mind please share.

Regexp looked more promising, should we focus there first?

Philippe

Re: Namespaces - summary, conclusion

[Philippe Vaucher]

> I think consistency is important, and if the language itself wants naming
> things the ‘lisp-way’, I’m fine with a consistent naming scheme. I’m not sure
> if you’d agree or not, but maybe trying to find a consistent naming scheme
> and
> documenting them (which was called as the ‘lisp-way’ by some) might be first.
> And then we can rename the ones that don’t follow them.

That makes a lot of sense.


> What does everybody think about this? I think it would be less disruptive and
> controversial if some Elisp core API guidelines are decided, written, and
> followed in the future. Then, if it turns out it’s useful enough, we can
> start
> aliasing functions that don’t follow them to names that do follow them (if
> it’s desirable to do so.)

It'd also be easier for future discussions to point out to the current
"standard", and for people to propose changes.

Re: Namespaces - summary, conclusion

[Philippe Vaucher]

> > Having multiple names for the same thing also reduces discoverability,
>
> Even worse yet, as has been mentioned (but is often forgotten), it
> makes code readability harder.

I think it depends on the reader. I know that for me it'd greatly
improve discoverability and make code readability easier. But I
understand that it also creates noise when listing functions or
reading code for those who'd not use them, thus having the opposite
effect.

Re: Namespaces - summary, conclusion

[Philippe Vaucher]

> > rename-file -> file-rename
> > delete-file -> file-delete
> > copy-file -> file-copy
> > expand-file-name -> file-expand-name
>
> These are different: in Emacs we have functions that work on _files_,
> and we have functions that work on _file names_.  The first 3 above
> are of the former kind, the last one is of the second kind (there are
> a lot more of that kind).  We shouldn't mix them.

What is commonly done in other languages for functions operating on
paths only is to be prefixed with "path-".

rename-file -> file-rename
delete-file -> file-delete
copy-file -> file-copy
expand-file-name -> path-expand

That does not solve the interesting point about the first 3 being
interactive functions. Maybe interactive warrant english-looking
conventions ("verb-object")? This complicate matters.

Re: Namespaces - summary, conclusion

[Alfred M. Szmidt]

   What is commonly done in other languages for functions operating on
   paths only is to be prefixed with "path-".

Huh?  expand-file-name doesn't act on paths.

Re: Namespaces - summary, conclusion

[Alfred M. Szmidt]

That would be a terribly misleading name for expand-file-name, since
it has nothing to do with pathnames or paths, expand-file-name works
on file names only.

Re: Namespaces - summary, conclusion

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Mon, 4 May 2020 18:36:46 +0200
> Cc: Stefan Kangas <stefan@marxist.se>, Emacs developers <emacs-devel@gnu.org>
> 
> > > rename-file -> file-rename
> > > delete-file -> file-delete
> > > copy-file -> file-copy
> > > expand-file-name -> file-expand-name
> >
> > These are different: in Emacs we have functions that work on _files_,
> > and we have functions that work on _file names_.  The first 3 above
> > are of the former kind, the last one is of the second kind (there are
> > a lot more of that kind).  We shouldn't mix them.
> 
> What is commonly done in other languages for functions operating on
> paths only is to be prefixed with "path-".

GNU Coding standards frown on using "path" for anything but PATH-style
directory lists.  Compare with load-path, exec-path, etc.

Re: Namespaces - summary, conclusion

[Stefan Monnier]

> rename-file -> file-rename
> delete-file -> file-delete
> copy-file -> file-copy

I have no opinion on the "file-" namespace (I haven't looked enough
into it to have an opinion).

> expand-file-name -> file-expand-name

This one should be under the `file-name-` prefix.
Almost all other file-name manipulation functions are already there.


        Stefan

Re: Namespaces - summary, conclusion

[Philippe Vaucher]

> This one should be under the `file-name-` prefix.
> Almost all other file-name manipulation functions are already there.

That works for me.

Philippe

RE: Namespaces - summary, conclusion

[Drew Adams]

> > This one should be under the `file-name-` prefix.
> > Almost all other file-name manipulation functions are already there.
> 
> That works for me.

Actually, it's most, but not almost all.

There are quite a few functions dealing
with file names that have `filename',
not `file-name', in their name.  I'm
guessing that includes some that might
be called "file-name manipulation"
functions.  (I see none, however that
use `filename-' as a _prefix_.)

(And no, such inconsistency is not very
important, IMO.)

Re: Namespaces - summary, conclusion

[Stefan Monnier]

> What is commonly done in other languages for functions operating on
> paths only is to be prefixed with "path-".

What is sometimes called "path" we call "file-name", hence the
"file-name-" prefix.


        Stefan

Re: Namespaces - summary, conclusion

[chad]

[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]

As long as we're still talking about summary & conclusion, I think that you
left out an important likely outcome: People outside of the emacs core
continue to build more "language cleanup/improvement" libraries. My
evidence is roughly "proof by existence", in particular because what
started with dash.el and perhaps cl{,-lib}.el has continued to expand over
time with things like s.el and f.el (small sample size, biased observer,
etc.). Supporting evidence is that such systems are common in popular
current languages (to my knowledge, JavaScript itself has between a couple
and a dozen, depending on how you count).

While this isn't what I would personally consider the best outcome for
emacs as a whole, it's probably not terrible. It seems to me that the way
to optimise this world for emacs-devel is to try to help any major examples
get added to GNU ELPA, because the default/bad case seems to something like
"add them to MELPA, use them, and create a widening dependency on MELPA"
for future elisp code. (As a hypothetical example, I could imagine a world
where a Spacemacs successor both becomes the "baseline emacs" for a
generation of programmers and requires code that's available only via MELPA
or github.)

I bring this up to encourage others to join the effort to get MELPA
packages available on GNU ELPA.

Thanks,
~Chad


On Mon, May 4, 2020 at 2:27 AM Philippe Vaucher <philippe.vaucher@gmail.com>
wrote:

> Hello,
>
> I think for my part the amount of bikeshedding done was enough now and
> I can come to some conclusions.
>
> The proposal of aliasing or renaming Elisp functions that some of us
> feel inadequately named/grouped got mostly a strong resistance by what
> can be considered iconic figures of this community. I think that
> cannot be taken lightly.
>
> Here's a non exhaustive list of the counter-arguments, roughly ordered
> how I feel are the best arguments to the not-so-relevant but
> interesting:
>
> - Adding new aliases, while improving the experience of those who like
> to do an exact search for the regexp "^domain-.*", will degrade the
> experience of those who like to search the manual "the classic way"
> using "C-h d" or "C-h a".
> - Adding new aliases or renaming functions might confuse the users
> that are used to the current names. For example they might not
> immediately understand that "re-search-in-string" means "string-match"
> and have to look it up, wasting time.
> - Adding new aliases increases the memory usage, the size of the
> manual, and the amount of things to maintain.
> - Emacs Lisp is fundamentaly a language where all concepts intermix
> and thus is chaotic by nature, trying to organize it into categories
> is against history and does not make sense.
> - Even if we agree not to even touch the function name other than
> adding a prefix (e.g `keep-lines` becoming `buffer-keep-lines`),
> people will disagree on which prefix to use or about the genericity of
> a function making it unprefixable, or that's it's a crime to history,
> and thus consensus will be impossible to attain for almost every
> proposed function.
>
> Given this is more or less the position held by Alan, Eli, Richard,
> Drew and João I think the chances of seeing new aliases is close to 0.
> Until now every one of the proposed aliases (in string- or regexp-)
> were rejected for arguably good reasons but the message is pretty
> clear, I think aliases in Emacs core are a dead end (for now, that
> might change later) and will only live in libraries in MELPA (or ELPA
> is authors care).
>
> So, the altenatives proposed are, ordered by chances of seeing it
> happening:
>
> - Not rename anything, write some completion function that first
> completing-read one of the section at
> https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html,
> then using tricks to collect all function names there completing-read
> that list of functions. Might be bound to a new "C-h <somekey>".
> - Improve the sorting algorithm so somehow the function names
> associated with a topic are automatically but to the top when you
> search one of the "obvious" keywords like "alist" or "regexp". The
> path toward that solution is pretty unclear to me, feel free to expand
> on it.
> - Add namespaces to Emacs Lisp.
>
> Then there are other discussions going on, like the manual not
> offering a "tutorial view" with highlighted examples, but I think
> these are other discussions and should be discussed on their own.
>
> Kind regards,
> Philippe
>
>

[-- Attachment #2: Type: text/html, Size: 5381 bytes --]

Re: Namespaces - summary, conclusion

[조성빈]

조성빈 <pcr910303@icloud.com> 작성:

> Philippe Vaucher <philippe.vaucher@gmail.com> 작성:
>
>>>> Given this is more or less the position held by Alan, Eli, Richard,
>>>> Drew and João I think the chances of seeing new aliases is close to 0.
>>>
>>> This is not my conclusion.  I've seen several calls to move away from
>>> from discussing in the abstract to discuss specific, concrete
>>> examples.  I think this is a good idea, since IMHO the abstract
>>> discussion is likely exhausted.
>>>
>>> There is always the chance that some of the proposals will be voted
>>> down.  But also consider that some who have disagreed with you in the
>>> abstract might be more convinced by specific, concrete proposals.
>>
>> So far the string- proposal got shot down entirely. The regexp one was
>> initially a no-go from Alan but I then Richard kinda liked it and
>> proposed adaptations.
>>
>> @Stefan Monnier: I see that you talked about `multibyte-string-p`
>> already (and iirc that didn't went well. You talked earlier about
>> `process-`, maybe you'd like to propose some changes there?
>
> I think for people to propose changes and get them adapted, we first have  
> to
> have some proper goals to target.
>
> So there are a few people here who think renaming some functions is  
> beneficial
> - but everybody’s reasoning is different here. Some people who are  
> opposed to
> renaming are a bit confused.
>
> I think the two big goals are consistency and discoverability. And then  
> there
> are various small arguments like it’s easier to use prefix based  
> completion and
> function search, it’s easier to guess, namespace means less function name
> clashing, etc…
>
> I think consistency is important, and if the language itself wants naming
> things the ‘lisp-way’, I’m fine with a consistent naming scheme. I’m not  
> sure
> if you’d agree or not, but maybe trying to find a consistent naming  
> scheme and
> documenting them (which was called as the ‘lisp-way’ by some) might be  
> first.
> And then we can rename the ones that don’t follow them.
>
>> I mean I'm willing to propose concrete changes but if it's not obvious
>> for string- and regexp- why would it be for other topics? Let's try
>> another topic just to see:
>>
>> rename-file -> file-rename
>> delete-file -> file-delete
>> copy-file -> file-copy
>> expand-file-name -> file-expand-name
>>
>> Do you think people will be ok with that?
>
> The reason why I said about finding the naming scheme was because both the
> function name rename-file and file-truename makes sense to me.
>
> I think some preliminary conventions that Elisp already follows is that the
> <action>-<object> scheme is for actions on the object like rename-file or
> clear-string, and <object>-<property> scheme is for getting properties of  
> the
> object like string-width and file-name-extension. (I’m not considering
> polymorphic ones.)
>
> But then there are exceptions, like string-trim (which should then be
> trim-string) or string-join (which should then be join-string).
>
> What does everybody think about this? I think it would be less disruptive  
> and
> controversial if some Elisp core API guidelines are decided, written, and
> followed in the future. Then, if it turns out it’s useful enough, we can  
> start
> aliasing functions that don’t follow them to names that do follow them (if
> it’s desirable to do so.)

I’ve CCed some Elisp users that I think would have some knowledge and  
opinions
about this - can people dial in and codify the ‘lisp-way’ or the ‘elisp-way’
so that we can have some starting point of the API guidelines?

(If someone is opposed to making an API guideline, can somebody explain the
  reasons too?)

Re: Namespaces - summary, conclusion

[Alfred M. Szmidt]

My mail client ate it self.  Sorry for the double..