From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ilya Shlyakhter Newsgroups: gmane.emacs.devel Subject: Re: CL package suggestion Date: Mon, 9 Apr 2012 12:54:11 -0400 Message-ID: References: <27y5qciwgd.fsf@fencepost.gnu.org> <9lty10iwdr.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf302d49c801de7004bd41db7f X-Trace: dough.gmane.org 1333990466 15206 80.91.229.3 (9 Apr 2012 16:54:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 9 Apr 2012 16:54:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 09 18:54:25 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SHHrF-0002uc-6P for ged-emacs-devel@m.gmane.org; Mon, 09 Apr 2012 18:54:25 +0200 Original-Received: from localhost ([::1]:59964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHHrE-0007Kf-Lw for ged-emacs-devel@m.gmane.org; Mon, 09 Apr 2012 12:54:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHHrB-0007KP-7g for emacs-devel@gnu.org; Mon, 09 Apr 2012 12:54:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SHHr9-0001AH-9p for emacs-devel@gnu.org; Mon, 09 Apr 2012 12:54:20 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:34571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHHr4-0000vg-0i; Mon, 09 Apr 2012 12:54:14 -0400 Original-Received: by yenm8 with SMTP id m8so2272481yen.0 for ; Mon, 09 Apr 2012 09:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UnNW/lJmRYkqU72rX8JOq/+4h4FjA161gQBDoYpwxtA=; b=aO8KRitPjl4hE8NQssN63y/qIoIuBnl1bykdEnPU6xISmTbquEt03oLys7UbFvkQIz zz83dqXPPd0ge+12B71telYxOrD84jmSl42FBa2/wbck8TKy6vNvU31uOmcfwe2lQaQh fuJ4T/5Sh5pSrG0lSP5VLuL3OcP1hpm3T35TRR0Dd1UIuwamqOxHFSZltnq2hfXxjNsO DPDxZ/0vTd5AAQ1tMRYe456pPIBscbFrZU6KnS/NSR42jljVGAu5XM8e+VLoEoDGzA8M GqqA0wWwNwjC68SEZXLDDrN2JQiI9Ex/5OuZ9nRlj0ZTCY2gw9xf6V8/Ecedp1lWXP4S OYqQ== Original-Received: by 10.236.154.2 with SMTP id g2mr6545786yhk.103.1333990451699; Mon, 09 Apr 2012 09:54:11 -0700 (PDT) Original-Received: by 10.147.168.13 with HTTP; Mon, 9 Apr 2012 09:54:11 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: UiVpv9f46F7PYUKO7a9xsc7KEHg X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.213.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:149524 Archived-At: --20cf302d49c801de7004bd41db7f Content-Type: text/plain; charset=ISO-8859-1 p.s. cl-compat is taken (though obsolete), so that's not an option. On Mon, Apr 9, 2012 at 12:45 PM, Ilya Shlyakhter wrote: > cl-clean sounds a bit like a development stage in a project (alpha, beta, > clean...) -- might be confusing as a permanent > package name? other than that, sounds good. > > other possibilities: > cl2 > cl-new > cl-compat > cl-ext > cl-exts > cl-extensions > > btw, the name prefix will stay as cl- , as in cl-remove-if, whatever the > 'require symbol, correct? > > also, should the names be changed everywhere in the CL package manual, or > just add a separate section > saying that the following names should really be prefixed? > > also: should i also add cl- aliases for macro names in CL, for uniformity? > eg proclaim is a function while declaim > is a macro, but should the user have to keep that in mind or just use > cl-proclaim and cl-declaim and have it work? > > On Mon, Apr 9, 2012 at 12:24 PM, Stefan Monnier wrote: > >> > Maybe cl-runtime, or cl-rt? >> >> I'd rather not insist on the "runtime" side. It will just be the new >> canonical name of "cl". We can't use "cl" because too many package >> presume an implementation of "cl" which is not namespace clean, whereas >> the new "cl" will be namespace-clean. >> >> Maybe 'cl-clean' ? >> >> >> Stefan >> >> >> > We need a (require 'cl-) which brings up CL but only within >> >> the "cl-" namespace. I don't have a good idea for naming. `cl-defs' >> >> might be OK, but I'm open to other suggestions. Maybe `cl-layer', or >> >> `cl-emu', or `cl-compat'? >> >> `cl-funs' is another option, indeed. >> >> >> > > --20cf302d49c801de7004bd41db7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable p.s. cl-compat is taken (though obsolete), so that's not an option.
=
On Mon, Apr 9, 2012 at 12:45 PM, Ilya Shlyak= hter <ilya_sh= l@alum.mit.edu> wrote:
cl-clean sounds a bit like a development sta= ge in a project (alpha, beta, clean...) -- might be confusing as a permanen= t
package name? =A0other than that, sounds good.

oth= er possibilities:
cl2
cl-new
cl-compat
cl-ext
cl-exts=
cl-extensions

btw, the name prefix will= stay as cl- , as in cl-remove-if, whatever the 'require symbol, correc= t?

also, should the names be changed everywhere in the CL = package manual, or just add a separate section
saying that the fo= llowing names should really be prefixed?

also: sho= uld i also add cl- aliases for macro names in CL, for uniformity? =A0eg pro= claim is a function while declaim
is a macro, but should the user have to keep that in mind or just use = cl-proclaim and cl-declaim and have it work?

On Mon, Apr 9, 2012 at 1= 2:24 PM, Stefan Monnier <monnier@iro.umontreal.ca> wr= ote:
> Maybe cl-runtime, or cl-rt?

I'd rather not insist on the "runtime" side. =A0It will just = be the new
canonical name of "cl". =A0We can't use "cl" becaus= e too many package
presume an implementation of "cl" which is not namespace clean, w= hereas
the new "cl" will be namespace-clean.

Maybe 'cl-clean' ?


=A0 =A0 =A0 =A0Stefan


> We need a (require 'cl-<something>) which brings up CL but o= nly within
>> the "cl-" namespace. =A0I don't have a good idea for= naming. =A0`cl-defs'
>> might be OK, but I'm open to other suggestions. =A0Maybe `cl-l= ayer', or
>> `cl-emu', or `cl-compat'?
>> `cl-funs' is another option, indeed.
>>


--20cf302d49c801de7004bd41db7f--