RE: Imports / inclusion of s.el into Emacs

[Drew Adams <drew.adams@oracle.com>]

> > Renaming 'concat' seems also like spurious inconvenience
> > in the name of rigidity -- the Lisp equivalent of 
> > bureaucratese.

Yes.  Spurious inconvenience for users, even if
well-intentioned.

> We all do keep in mind that 'concat' is about much
> more than strings, yes?  Such polymorphic APIs are
> IMO a problem when a simplistic re/naming is considered.

Exactly my thought.  Likewise, `format' - an even
better example.
___

The idea that every function that returns an XYZ
instance, or that operates on one, should have a
name prefix (e.g. `xyz-') that advertises that
fact is, well, somewhat silly, and it can border
on dogmatism.

My guess is that this is coming, not just from an
Emacs UI question involving prefix completion and
discoverability, but more generally from the
widespread influence of OOP, where categorizing
or grouping of functions (methods) etc. by type
(class) of object acted on or returned has become
ingrained mentally as the only or the best or the
main way to organize them. 

That things _can_ be usefully grouped thus is not
a reason why they always should or must.  That may
be a requirement in some OOP languages, but it's
not so in theory or in other programming contexts.

Functions are more varied than what's necessary to
define an abstract data type (class).  Yes, a
particular set of functions do define an ADT, but
other functions can also make use of it.

It would be absurd to name every function that
uses or returns an integer with prefix `int-'.
(Polymorphism can help get around this in OOP.) 

In Haskell, do you name every function with a
prefix that advertises the type of its return
value or one of its main arguments?  No, of course
not.  How do you find functions that return or use
a value of a given type?  You check signatures
or doc.

As for "alist", "ass(q|oc)", and the like: each
such choice has its drawbacks.  But yes, some name
consistency can help, in general.  But no, because
history.  And no, because different uses/contexts.

The discussion was motivated by considering new
users, in particular.  Well then, what does a new
user look for, when it comes to alists?  Does s?he
know the term "alist"?  Or is the thought about
"association"? "key-value"? "pair"? "relation"?
"attribute-value"? "property-value"?

Consider "plists".  Does a newbie whose heard
something about them and tries to find relevant
functions look for "plist"? "property"? "prop"?
"tag"? something else?

There is no blanket, simple "solution" to this,
because people come from different places/contexts
and think in different terms/languages.  Should
Emacs generally be consistent?  Sure.  Could it
have been more consistent at the outset (Lisp Day
One)?  Probably.  Is there now, here & there, room
for improvement in naming functions?  Sure.

Should we be wholesale-renaming stuff, especially
to try to fit what the latest generation of
newbies might be most used to?  Absolutely not.
Names should be considered case by case.  And
there's zero "fierce urgency of now" for any
particular renaming Long March (initiative).
___

Don't downplay the use of matching against more
than the function name.  As Eli mentioned:
`C-h d', which matches also against a function's
doc.  And as I and others have mentioned: more
flexible matching methods.

Consider `C-h f alist', with substring matching.
In my current session I get 156 candidates, all
of which are relevant to alists.  Great.

If I match `ass' instead, I get 235 candidates,
many of which are about alists, but many of which
are not.  If I then chip away from those matches
the matches for `class' and `pass', I get only 51
matches, of which 34 are about alists.

(The 17 matches that are not about alists:
ad-assemble-advised-definition
2C-associated-buffer
ad-assemble-advised-definition
assert
byte-compile-associative
byte-optimize-associative-math
byte-optimize-nonassociative-math
cl--assertion-failed
cl-assert
disassemble
disassemble-offset
glasses-mode
gnus-atomic-progn-assign
image-dired-associated-dired-buffer
image-dired-associated-dired-buffer-window
message-disassociate-draft
nndraft-request-associate-buffer)

If I use `C-h d alist' I find 560 functions
whose doc mentions "alist".
`C-h d association list' finds 56 functions.
`C-h d assoc' finds 52 functions.
___

Finally, the habit of assuming that functions
should be grouped only by argument or return
type, either in terms of name or doc, is not
a guide.  API doc (e.g. JavaDoc) does have its
uses.  And it's especially useful, perhaps
even necessary, for certain kinds of languages
(e.g. OOP).  But it's certainly not the be-all
and end-all.

Lisp is not Java.  Discoverability for Lisp is
not discoverability for Java.  Doc for Lisp is
not doc for Java.

It does take some time for a newbie to learn
to "ask Emacs", including wrt using Lisp to
ask.  And sure, we can help ease entry.  But
that's not a reason to try to mold Emacs help
(including naming) into only what newbies
might be used to in other contexts.