Re: map.el and naming

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > of these objects: lists, strings, vectors, alists, and hash-tables?
 > 
 > Think of `seq' and `map' as (Java) interfaces, which can be implemented
 > by various low-level representations.
 > 
 > Some representations (e.g. lists or vectors) can implement both interfaces.

Please, let's not go there.  Emacs Lisp is by design, history, and
current practice in Emacs primarily a non-object-oriented language.
It's not object-oriented at the level of Java or Haskell, and
certainly not Smalltalk.  Granted, it is certainly possible to
implement true[1] objects in Lisp, and it's a very valuable technique
in Emacs too (eg, the various components of CEDET).

But the "objects" listed in the quote above are not objects in this
sense.  They don't know their own subclass, and so cannot tell a
function operating on them that "I'm a cons" (Lisp knows that) "which
is the head of a list representing a map using the 'property list'
API" (Lisp can't know that for those objects).  This is a deliberate
design principle; RMS wanted Emacs data structures to be
introspectable, and he chose to do that by avoiding ADTs except where
absolutely necessary for efficiency (buffers, strings, vectors,
hash-tables), and instead building everything out of a few primitive
data types and embedding knowledge of data structures in functions.
This allows a person with access to the source of those functions to
introspect the corresponding data structures.  (How 1970s!  Sure, but
that's when Emacs was designed....)

Certainly it's possible to implement polymorphic functions, too.  But
here, AFAICS we already have the useful ones for sequences (nth, for
one).  I agree that "cons", "car", and "cdr" are not very discoverable
for new learners, but then the ambiguous use of "map" (as a verb, it
either means "iterate over a sequence" or "describe a functional
relationship") is hardly helpful to them.  I really don't see what
benefit these new faux-namespaces (seq.el, map.el) provide, except to
worshippers of consistency.  This is quite different from the
situation with cl-lib, where Common Lisp often uses the same
identifiers as Emacs Lisp with different semantics, and also often
provides rather sophisticated functionality that is not necessary in
"base Emacs" (though extremely expressive and useful in the advanced
applications which make Emacs so powerful).

If you want to build an object-oriented language into Lisp, great.
But first you need objects.  (XEmacs already uses OO implementation
techniques at the C level, but I gather from other threads that in
Emacs such usage is spotty at best.)  We already have EIEIO.  That may
not be appropriate for "promotion" into the core language, or perhaps
people would prefer CLOS or maybe something more appropriate for an
eventual Guile-based Emacs "Lisp".

Footnotes: 
[1]  By which I mean in the conventional sense of "object orientation".