unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Pascal Bourguignon <spam@thalassa.informatimago.com>
Subject: Re: Some racism in emacs!
Date: 02 Jun 2003 08:42:20 +0200	[thread overview]
Message-ID: <873citkmk3.fsf@thalassa.informatimago.com> (raw)
In-Reply-To: 87n0h2jldb.fsf@indigo.shootybangbang.com


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

Who asked for a subset?
 
> 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.

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?



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


-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.

  reply	other threads:[~2003-06-02  6:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-01  6:05 Some racism in emacs! Pascal Bourguignon
2003-06-01  7:41 ` John Paul Wallington
2003-06-02  6:42   ` Pascal Bourguignon [this message]
2003-06-02  9:46     ` John Paul Wallington
2003-06-02 13:08       ` Kai Großjohann
2003-06-02 16:00         ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873citkmk3.fsf@thalassa.informatimago.com \
    --to=spam@thalassa.informatimago.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).