Re: cc-langs.el

[Martin Stjernholm]

Miles Bader <address@hidden> wrote:

> _Emacs lisp is not common lisp_.
>
> That means that however worthy these functions are (and I know they are
> -- remember, I'm a common-lisp _fan_*), you can't just plop them into
> elisp wholesale, you've got at least look at them, and how they fit into
> elisp, and make decisions; interfaces and functions that are right for
> common-lisp are not necessarily right for elisp.  For a lot of
> functions, that takes a fair amount of time.

That was the intention with my list in this discussion; we
collectively take a look on them and then, hopefully, agree on a set
to include. I don't see how that could take an awful lot of time, but
even if it does it's time well spent imho.

Just saying "it's too much, it won't happen, e.o.d." is not good
enough; I won't accept that as a reason for having to write cumbersome
extra code to avoid these functions.

> I realize that for sanity's sake, it would be best to use the same (or
> at least very similar) interfaces for elisp functions as their
> common-lisp counterparts, /.../

That's a very compelling reason for not meddling with their
interfaces. An important point in "blessing" the CL functions instead
of inventing something else is that they already been around for quite
a while and are used in many places, albeit "only" at compile time in
the standard packages.


So, to further concretize the discussion let's bring up the specific
issues that need to be considered. I can think of the following:

o  There are functions among the suggested ones that shouldn't be
   "blessed" for some reason. Well, I've already weeded out the ones
   that try to fix things like lexical binding and other stuff I
   suspect aren't reliable enough. Among those who remain that might
   be dubious are:

   -  define-compiler-macro, if it doesn't work well enough with the
      compiler (otherwise it appears to be really useful), and
   -  defstruct, which does a lot of stuff that I don't know how well
      it works (I've got no personal experience with it), and
   -  more?

o  There might be more functions in the CL package that deserve to be
   considered. If so, those can be discussed later.

o  The CL map functions all accept more than one list to iterate over,
   whereas the built-ins only take one. When the function mapc got
   added as a built-in it lost that feature (which is a potential
   compatibility issue).

   I suggest that the multiple lists feature is kept, partly because
   it's useful occasionally, partly because it's compatible, and
   partly because it's no work (provided the functions remain written
   in lisp). It would lead to a slight inconsistency with the built-in
   mapcar and mapc, but that's only a minor ugliness that can be fixed
   later on without compatibility trouble.

o  The CL sequence and set functions all take keyword arguments like
   ":test" and ":key". That design is not new in elisp so it shouldn't
   be a problem per se, and the keywords are consistent and (imho)
   appropriate.

   Keeping those keywords introduces an inconsistency with the
   built-ins sort, remove, delete, member, assoc, and rassoc. The case
   is the same here as with mapcar and mapc: It's only a bit ugly and
   can be fixed at any time. Until then the CL counterparts ending
   with "*" can be used.

o  All the CL functions default to eql as test predicate, whereas the
   built-ins delete, remove, member, assoc, and rassoc use equal. This
   is also an inconsistency issue, but it's more serious since it
   can't be fixed without potential incompatibilities.