Re: Some racism in emacs!

[John Paul Wallington]

Pascal Bourguignon <spam@thalassa.informatimago.com> wrote:

> John Paul Wallington <jpw@gnu.org> writes:
>> The cl library, like Common Lisp, is big and hard to subset.
>
> Who asked for a subset?

The coding conventions say not to make runtime use of cl.  IMHO, the
most likely to succeed way to nullify this convention is to split cl
into independent parts and for libraries to require what they need at
runtime.  But subsetting cl is almost as hard as subsetting Common
Lisp.

>> Amongst the Emacs Lisp Coding Conventions it is suggested:
>> 
>>    * Please don't require the `cl' package of Common Lisp extensions at
>>      run time.  Use of this package is optional, and it is not part of
>>      the standard Emacs namespace.  If your package loads `cl' at run
>>      time, that could cause name clashes for users who don't use that
>>      package.
>> 
>>      However, there is no problem with using the `cl' package at compile
>>      time, for the sake of macros.  You do that like this:
>> 
>>           (eval-when-compile (require 'cl))
>> 
>> Hm.  I think name clashes are largely a non-problem; a package author
>> would be insane to define cl functions/macros incompatibly, wouldn't
>> they?
>> 
>> Ways to ameliorate this situation include splitting cl into several
>> separate independent libraries, moving ultra-nifty bits into subr.el,
>> or defining compiler macros for the more popular functions.
>> 
>> If you just don't want to see the warnings then try frobbing
>> `byte-compile-warnings' (untested).
>
> This is entirely negating the point of Common-Lisp and the `cl' package.
>
> I  don't use Microsoft-Word  because I  don't want  to be  locked into
> their proprietary file format.
>
> By the same token, as much as possible, I don't want to be locked into
> emacs lisp specificisms.
>
> Everytime  there is  an  emacs  function that  have  an equivalent  in
> Common-Lisp, I'll use the Common-Lisp  version.  This gives me the big
> bonus to be able to use most  of my lisp code programmed on emacs also
> on any other lisp environment.

I see.  But cl doesn't magically make Emacs Lisp into Common Lisp.  I
guess you could write sizable code that does the same thing under
both, but would it particularly suit either?

> But I  guess that this gives the  same cold sweat to  Stallman than to
> Gates,  to  see that  some  users  of his  programs  may  want to  use
> concurent programs!   What if  suddently GNUS or  VM or Kiwi  could be
> compiled and used with cmucl or clisp?  Horror!
>
>
> I don't mind if features specific  to the emacs editor are hard linked
> to it  (instead of, for example,  being programmed as  a nice portable
> Common-Lisp package).  There may  have valid technical reasons for it,
> or I could even  agree with their moral reasons for it.   But if I use
> emacs for  prototyping lisp  code, for scripting,  or even  to program
> some  personal interactive  tools, why  should they  and all  the lisp
> libraries I write be locked to emacs lisp?

Because that's the way it is.  Emacs implements its own dialect.

I imagine an Emacs written in Common Lisp would probably be better off
using Common Lisp as its extension language.

> If emacs developers are worried by name clashes, what are they waiting
> for implementing Common-Lisp packages?