CL package suggestion

CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

hello,

i'd like to make a suggestion for the CL package.
right now its non-macro parts can't be used at runtime.
as a result, each package defines their own equivalents, e.g. org-remove-if.

could Emacs add a copy of the CL package with some standard prefix, e.g.
ecl?
then with (require 'ecl) you get ecl-remove-if etc.
the ecl or whichever prefix has to avoid conflict with known emacs
packages,
but that's it.  the issues with polluting the global namespace /
conflicting with
people's private remove-if versions would not apply.

the alternative is that for each package i write i copy code i need from CL
(with
acknowledgement of course) and add my package's prefix.  that doesn't
seem ideal.

thanks,

ilya

[-- Attachment #2: Type: text/html, Size: 965 bytes --]

Re: CL package suggestion

[Glenn Morris]

Ilya Shlyakhter wrote:

> could Emacs add a copy of the CL package with some standard prefix, e.g.
> ecl?

This was discussed extensively recently, and somebody volunteered to do
basically that:

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00249.html

Nothing happened, now it is too late for Emacs 24.1.

Re: CL package suggestion

[Glenn Morris]

Glenn Morris wrote:

> now it is too late for Emacs 24.1.

Though to be honest, it probably was too late already in February.

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

I'm just glad this is being considered :)  It'd be great to see this in
24.2 .

On Tue, Apr 3, 2012 at 1:00 PM, Glenn Morris <rgm@gnu.org> wrote:

> Glenn Morris wrote:
>
> > now it is too late for Emacs 24.1.
>
> Though to be honest, it probably was too late already in February.
>

[-- Attachment #2: Type: text/html, Size: 573 bytes --]

Re: CL package suggestion

[Stefan Monnier]

> I'm just glad this is being considered :)  It'd be great to see this in
> 24.2 .

Patch welcome (and BTW, I'd prefer the "cl-" prefix over the "ecl-" prefix).
It's never too early to start.


        Stefan

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Agree about cl- being better than ecl- .

Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two calls
indistinguishable
to the byte compiler?   If they are, and calling cl-remove wouldn't trigger
a warning,
wouldn't remove-if calls also become warning-less?   And if they would,
isn't it simpler
to just allow calling remove-if? :)

ilya

On Tue, Apr 3, 2012 at 2:58 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > I'm just glad this is being considered :)  It'd be great to see this in
> > 24.2 .
>
> Patch welcome (and BTW, I'd prefer the "cl-" prefix over the "ecl-"
> prefix).
> It's never too early to start.
>
>
>        Stefan
>

[-- Attachment #2: Type: text/html, Size: 1088 bytes --]

Re: CL package suggestion

[Stefan Monnier]

> Agree about cl- being better than ecl- .
> Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two calls
> indistinguishable to the byte compiler?

The name is different, so the compiler can definitely tell the difference.

> If they are, and calling cl-remove wouldn't trigger a warning,
> wouldn't remove-if calls also become warning-less?

Not necessarily, no.


        Stefan

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

Right now, the cl package itself seems to violate the rule against calling
its functions at runtime.
E.g.

(define-compiler-macro assoc* (&whole form a list &rest keys)
;; ...
           (if (floatp-safe (cl-const-expr-val a))
 ;; ...

floatp-safe is a function in package cl, and the compiled code will call it
at runtime.
Am I missing something?

On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > Agree about cl- being better than ecl- .
> > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two
> calls
> > indistinguishable to the byte compiler?
>
> The name is different, so the compiler can definitely tell the difference.
>
> > If they are, and calling cl-remove wouldn't trigger a warning,
> > wouldn't remove-if calls also become warning-less?
>
> Not necessarily, no.
>
>
>        Stefan
>

[-- Attachment #2: Type: text/html, Size: 1402 bytes --]

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

I'm sorry, the example I gave is fine -- that code of course is executed at
compile-time only.

On Sun, Apr 8, 2012 at 9:39 PM, Ilya Shlyakhter <ilya_shl@alum.mit.edu>wrote:

> Right now, the cl package itself seems to violate the rule against calling
> its functions at runtime.
> E.g.
>
> (define-compiler-macro assoc* (&whole form a list &rest keys)
> ;; ...
>            (if (floatp-safe (cl-const-expr-val a))
>  ;; ...
>
> floatp-safe is a function in package cl, and the compiled code will call
> it at runtime.
> Am I missing something?
>
> On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:
>
>> > Agree about cl- being better than ecl- .
>> > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two
>> calls
>> > indistinguishable to the byte compiler?
>>
>> The name is different, so the compiler can definitely tell the difference.
>>
>> > If they are, and calling cl-remove wouldn't trigger a warning,
>> > wouldn't remove-if calls also become warning-less?
>>
>> Not necessarily, no.
>>
>>
>>        Stefan
>>
>
>

[-- Attachment #2: Type: text/html, Size: 1834 bytes --]

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

So, about the cl package:

If remove-if is renamed cl-remove-if and then 'remove-if defaliased to
'cl-remove-if,
is it now ok to (require 'cl) at runtime?  Won't the alias now conflict
with whatever
definition of remove-if the user had?
And if you don't (require 'cl) at runtime, then you can't call cl-remove-if
at runtime,
since it might not be available.

One could move cl-remove-if etc into a separate module called cl-funcs,
so if you want to call cl-remove-if at runtime you (require 'cl-funcs).
This would somewhat break up the logical structure of the cl package,
since things will get grouped by whether they're functions or macros rather
than by topic.

Suggestions?

On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > Agree about cl- being better than ecl- .
> > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two
> calls
> > indistinguishable to the byte compiler?
>
> The name is different, so the compiler can definitely tell the difference.
>
> > If they are, and calling cl-remove wouldn't trigger a warning,
> > wouldn't remove-if calls also become warning-less?
>
> Not necessarily, no.
>
>
>        Stefan
>

[-- Attachment #2: Type: text/html, Size: 1786 bytes --]

Re: CL package suggestion

[Stefan Monnier]

> If remove-if is renamed cl-remove-if and then 'remove-if defaliased to
> 'cl-remove-if, is it now ok to (require 'cl) at runtime?  Won't the
> alias now conflict with whatever definition of remove-if the user had?
> And if you don't (require 'cl) at runtime, then you can't call
> cl-remove-if at runtime, since it might not be available.

We need a (require 'cl-<something>) 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'?

> One could move cl-remove-if etc into a separate module called cl-funcs,
> so if you want to call cl-remove-if at runtime you (require 'cl-funcs).

`cl-funs' is another option, indeed.

> This would somewhat break up the logical structure of the cl package,
> since things will get grouped by whether they're functions or macros
> rather than by topic.

No: The way to do it is to rename cl.el to cl-<something>.el, change all
its definitions to use the "cl-" prefix and then create a new cl.el
which only contains defaliases.


        Stefan

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

Maybe cl-runtime, or cl-rt?

We need a (require 'cl-<something>) 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.
>

[-- Attachment #2: Type: text/html, Size: 555 bytes --]

Re: CL package suggestion

[Stefan Monnier]

> 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-<something>) 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.
>> 

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

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 <monnier@iro.umontreal.ca>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-<something>) 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.
> >>
>

[-- Attachment #2: Type: text/html, Size: 2215 bytes --]

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

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 <ilya_shl@alum.mit.edu>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 <monnier@iro.umontreal.ca>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-<something>) 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.
>> >>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2634 bytes --]

Re: CL package suggestion

[Stefan Monnier]

> 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.

Not sure how much of a problem that is, but if people don't like it, we
can surely find something else: `cl-all', `cl-prefix'?

> other possibilities:
> cl2
> cl-new
> cl-compat
> cl-ext
> cl-exts
> cl-extensions

I don't like the "2" and "new" concepts here, since it's not
a reimplementation/redesign.  I didn't like "cl-ext" at first, but maybe
there's some sense to it.  How 'bout "cl-lib" instead?

> btw, the name prefix will stay as cl- , as in cl-remove-if, whatever the
> 'require symbol, correct?

Yes.

> 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?

We want to discourage the use of plain (require 'cl), so the manual
should reflect that and document the prefixed names.

> also: should i also add cl- aliases for macro names in CL, for uniformity?

That's a good question and I haven't thought much about it.  I'm leaning
towards the "yes" (e.g. I don't like the current dolist/dotimes
situation where those macros are defined in two different ways
depending on whether `cl' is loaded or not).


        Stefan

Re: CL package suggestion

[Richard Stallman]

    No: The way to do it is to rename cl.el to cl-<something>.el, change all
    its definitions to use the "cl-" prefix and then create a new cl.el
    which only contains defaliases.

Yes, that would be the right way.

My suggestions for names for the new package are cl-safe, cl-imp (for
implementation), or cl-nice (because it is nice to the namespace).

    > also: should i also add cl- aliases for macro names in CL, for uniformity?

    That's a good question and I haven't thought much about it.  I'm leaning
    towards the "yes" (e.g. I don't like the current dolist/dotimes
    situation where those macros are defined in two different ways
    depending on whether `cl' is loaded or not).

I agree.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: CL package suggestion

[Ilya Shlyakhter]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

Of the names mentioned so far, cl-lib seems best to me: what distinguishes
cl from most other packages is that it's a library of callable code rather
than
an implementation of some user-facing functionality.
cl-ext would also work for the same reason.

If the intention is to eventually obsolete and forget about the non-safe,
non-clean and non-nice version of cl, then cl-safe/cl-clean/cl-nice might
look strange in future code (suggesting that there's a
non-safe/non-clean/non-nice
version somewhere & the user is choosing the safe/clean/nice version for
their particular program).  Cf. car-safe, floatp-safe etc.

On Wed, Apr 11, 2012 at 12:18 AM, Richard Stallman <rms@gnu.org> wrote:

>    No: The way to do it is to rename cl.el to cl-<something>.el, change all
>    its definitions to use the "cl-" prefix and then create a new cl.el
>    which only contains defaliases.
>
> Yes, that would be the right way.
>
> My suggestions for names for the new package are cl-safe, cl-imp (for
> implementation), or cl-nice (because it is nice to the namespace).
>
>    > also: should i also add cl- aliases for macro names in CL, for
> uniformity?
>
>    That's a good question and I haven't thought much about it.  I'm leaning
>    towards the "yes" (e.g. I don't like the current dolist/dotimes
>    situation where those macros are defined in two different ways
>    depending on whether `cl' is loaded or not).
>
> I agree.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>  Use free telephony http://directory.fsf.org/category/tel/
>

[-- Attachment #2: Type: text/html, Size: 2382 bytes --]

Re: CL package suggestion

[Stefan Monnier]

> Of the names mentioned so far, cl-lib seems best to me: what distinguishes

OK, let's go with `cl-lib'.


        Stefan