Re: cc-langs.el

Re: cc-langs.el

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

> This code in cc-langs.el uses CL functions at run time.

Only if it isn't byte compiled, which isn't recommended. cc-langs is
not even loaded when everything is byte compiled.

> It won't work.

I still don't understand this aversion to the CL functions. I find it
absurd that there is an old and well established set of basic tools
that can't be used in many situations.

The only argument for that position I've heard is that the CL package
isn't namespace clean with some package prefix. That argument is weak
since it can't conceivably become a practical problem - the functions
are so old and well established that they are comparable to the
built-in functions. Anyone who would define a mapcan with any other
function than the one in CL would be both very silly and break the
namespace rules.

> (c-lang-defconst c-operator-list
>   ;; The operators as a flat list (without duplicates).
>   t (delete-duplicates (mapcan (lambda (elem) (append (cdr elem) nil))
> 			       (c-lang-const c-operators))
> 		       :test 'string-equal))
>
> There are further uses of mapcan in the same file.
>
> Please fix this, then ack by responding to this message.

Re: cc-langs.el

[Miles Bader]

On Fri, Aug 22, 2003 at 01:45:44PM +0200, Martin Stjernholm wrote:
> I still don't understand this aversion to the CL functions. I find it
> absurd that there is an old and well established set of basic tools
> that can't be used in many situations.

I can't speak for Richard, but my aversion is because cl is of extremely
variable quality -- much of it is very handy, but some of it really sucks (in
many cases unavoidably, because it tries to do things that don't fit well
into emacs' lisp engine, and unfortunately its all packaged as one big ball
of hair.  It's trying to provide compatibility that ultimately (1) can't be
done exactly, and (2) sometimes causes big performance problems by trying.

I would be a lot happier if the functionality were split up somehow, and the
uncontroversial bits basically made into a separate package that makes no
attempt to be `common-lisp,' but rather just tries to be a useful toolkit for
elisp, and is optimized for such.

[BTW, I love common-lisp, but cl is not it; sometimes it seems almost a
mockery...]

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0

Re: cc-langs.el

[Richard Stallman]

    > This code in cc-langs.el uses CL functions at run time.

    Only if it isn't byte compiled, which isn't recommended. cc-langs is
    not even loaded when everything is byte compiled.

I did not realize that.  So I guess the code does work.

    I still don't understand this aversion to the CL functions. I find it
    absurd that there is an old and well established set of basic tools
    that can't be used in many situations.

These functions are not a part of the Emacs Lisp namespace.
(And I don't want to add them and make the Lisp manual much bigger.)

    Anyone who would define a mapcan with any other
    function than the one in CL would be both very silly and break the
    namespace rules.

Any user can define a function called mapcan with any meaning at all.
If he put it in a Lisp package for publication, that name would be a
mistake, because he ought to put on a suitable prefix to avoid
conflicts.  But if he is just writing code for himself, that doesn't
apply.


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0

Re: cc-langs.el

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

> [CL] functions are not a part of the Emacs Lisp namespace.
> (And I don't want to add them and make the Lisp manual much bigger.)

I gather your reasoning is: They don't have a namespace prefix and
hence they are in the Emacs Lisp namespace, and all functions in the
Emacs Lisp namespace must be documented in the elisp manual.

Considering the complexity of many elisp applications there's clearly
a lack of basic utility functions in the elisp core, specifically
functions to operate on the built-in data types, e.g. the map, search
and replace functions in the CL package. There are many severe
drawbacks when every package with the need have to avoid or
reimplement them. Those drawbacks are so basic that I don't think I
have to elaborate on that.

So why shouldn't Emacs provide that functionality? Because of the size
of the manual? That's imho an odd priority, especially considering
that the navigational aids provided by Info and other browsing tools
easily can handle documentation of at least ten times the size of the
elisp manual.


Regarding the issue that Miles Bader raised: I don't request that the
entire CL library is "blessed"; I'm only talking about the functions
that operate on data, i.e. the things in cl-extra.el, cl-seq.el and
most of cl.el. Afaik they do their job well (or can at least be fixed
to do it well, as there aren't any basic design issues that they try
to cover up). The other more questionable stuff could very well remain
deprecated.

Re: cc-langs.el

[Richard Stallman]

    Considering the complexity of many elisp applications there's clearly
    a lack of basic utility functions in the elisp core, specifically
    functions to operate on the built-in data types, e.g. the map, search
    and replace functions in the CL package.

Some of these functions may indeed be worth adding, and we have
occasionally added some of them, but not the whole lot of them at
once.


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0

Re: cc-langs.el

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

> Some of these [CL] functions may indeed be worth adding, and we have
> occasionally added some of them, but not the whole lot of them at
> once.

I suggest that a fair number of them are considered in one go, so that
the core functions get reasonably complete in this regard. It hampers
development if every single one has to be advocated individually.
Afterall, they have all proven their general usefulness in a
CommonLisp context, and Emacs Lisp isn't all that different.

To concretize the discussion, I think the following functions are
generally useful and haven't got any direct counterparts in the
current set:

Predicates:
  eql

Map functions:
  mapcar*, cl-mapc (ought to be aliased to mapc* for consistency),
  maplist, mapl, mapcan, mapcon, some, every, notany, notevery
  
Number functions:
  signum, oddp, evenp

Sequence functions:
  subseq, reduce, fill, search, sort*, replace, replace*, remove-if,
  remove-if-not, delete*, delete-if, delete-if-not, substitute,
  substitute-if, substitute-if-not, nsubstitute, nsubstitute-if,
  nsubstitute-if-not, find, find-if, find-if-not, position,
  position-if, position-if-not, count, count-if, count-if-not,
  member*, member-if, member-if-not, assoc*, assoc-if, assoc-if-not,
  rassoc*, rassoc-if, rassoc-if-not, mismatch

Tree functions:
  tree-equal, subst, subst-if, subst-if-not, nsubst, nsubst-if,
  nsubst-if-not

List functions:
  ldiff, tailp, adjoin

Set functions:
  remove-duplicates, delete-duplicates, union, nunion, intersection,
  nintersection, set-difference, nset-difference, set-exclusive-or,
  nset-exclusive-or, subsetp

Property list functions:
  remprop

Place functions:
  incf, decf, pushnew

Macro functions:
  cl-macroexpand-all

Control structures:
  flet, macrolet, assert, define-compiler-macro, defstruct


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: cc-langs.el

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

>     To concretize the discussion, I think the following functions are
>     generally useful and haven't got any direct counterparts in the
>     current set:
>
> Sorry, that is far too much.

For what reason? The work of updating the manual?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: cc-langs.el

[Richard Stallman]

    >     To concretize the discussion, I think the following functions are
    >     generally useful and haven't got any direct counterparts in the
    >     current set:
    >
    > Sorry, that is far too much.

    For what reason? The work of updating the manual?

I don't even want to think about that many different functions, sorry.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: cc-langs.el

[Kevin Rodgers]

Richard Stallman wrote:

>     >     To concretize the discussion, I think the following functions are
>     >     generally useful and haven't got any direct counterparts in the
>     >     current set:
>     >
>     > Sorry, that is far too much.
> 
>     For what reason? The work of updating the manual?
> 
> I don't even want to think about that many different functions, sorry.

Martin's list has 82 functions.  In comparison, lisp/files.el defines
83 functions, lisp/simple.el defines 152 function, and src/*.c defines
1,058 (Lisp) functions.

The Common Lisp functions have a well-specified interface, and adding
new functions (vs. modifying existing functions) should not affect
Emacs' behavior.  What's to think about?


-- 
Kevin Rodgers

Re: cc-langs.el

[Miles Bader]

Kevin Rodgers <ihs_4664@yahoo.com> writes:
> The Common Lisp functions have a well-specified interface, and adding
> new functions (vs. modifying existing functions) should not affect
> Emacs' behavior.  What's to think about?

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

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, but none-the-less, you can't just plop.

-Miles

* Personally I'd love it if emacs used common-lisp instead of elisp.
  But it doesn't.
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: cc-langs.el

[Martin Stjernholm]

Miles Bader <miles@gnu.org> 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.

Re: cc-langs.el

[Miles Bader]

Martin Stjernholm <mast@lysator.liu.se> writes:
> 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.

Yeah, it probably couldn't hurt to discuss the various issues in detail
(if you've got enough time; rms probably doesn't of course).

I'll go over your list soon and mention the various problem areas I've
noticed in the past.

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: cc-langs.el

[Richard Stallman]

I am willing to consider a small number of functions for inclusion
as standard parts of Emacs.  I don't have time to consider a large
number, and I can't agree to them without considering them.

I do not like the Common Lisp style of using keyword arguments
for many common functions.  I basically do not have a very high
opinion of many of the decisions that were made in Common Lisp.

Adding the feature for iterating over multiple lists to mapc and
mapcar is fine with me.  I left that out only because I did not want
to do the work implement it.  If you want to write this, and do a
clean job, by all means do it.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Blessing cl functions

[Martin Stjernholm]

[Continuing an old thread here.]

Richard Stallman <rms@gnu.org> wrote:

> I am willing to consider a small number of functions for inclusion
> as standard parts of Emacs.  I don't have time to consider a large
> number, and I can't agree to them without considering them.

Then please take a look at as many as you are able to. I think it
bears repeating though, that the lack of such fundamental tools
continually hampers development in the small scale. Adding just a few
functions every year means almost unbearably slow progress in this
regard.

> I do not like the Common Lisp style of using keyword arguments
> for many common functions.

For functions that take a whole set of optional arguments I can't
think of any better alternative; keywords are at least better than
position-based argument passing. However they do incur higher runtime
overhead, but that should be possible to avoid with macros. Common
special cases can also be optimized to C level implementations. I can
devote some time to it if that would help matters.

> I basically do not have a very high opinion of many of the decisions
> that were made in Common Lisp.

The reasons for going with incompatible solutions would have to be
pretty strong, though, since the cl functions are de-facto used in
many packages (also those distributed separately). Nonconflicting
names would be a necessity to begin with, but even then one has to
consider the added confusion with two different libraries for the same
thing. The new library would have to be a lot better designwise to
motivate its existence, and when it comes to such basic stuff like
this I can't see how it can be done much differently.

> Adding the feature for iterating over multiple lists to mapc and
> mapcar is fine with me.  I left that out only because I did not want
> to do the work implement it.  If you want to write this, and do a
> clean job, by all means do it.

I could do that, especially if it would mean that the other mapping
functions (maplist, mapl, mapcan, mapcon, some, every, notany, and
notevery) got in too. None of those have keyword arguments, anyway.

(I probably have to extend my copyright assignment agreement first,
since it only covers CC Mode currently.)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Blessing cl functions

[Richard Stallman]

    I could do that, especially if it would mean that the other mapping
    functions (maplist, mapl, mapcan, mapcon, some, every, notany, and
    notevery) got in too. None of those have keyword arguments, anyway.

I don't like the idea of adding all of them, but a few of them would
be ok.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Blessing cl functions

[Miles Bader]

On Sun, Sep 21, 2003 at 06:33:37PM -0400, Richard Stallman wrote:
>     I could do that, especially if it would mean that the other mapping
>     functions (maplist, mapl, mapcan, mapcon, some, every, notany, and
>     notevery) got in too. None of those have keyword arguments, anyway.
> 
> I don't like the idea of adding all of them, but a few of them would
> be ok.

The last time I looked at this, BTW, the main annoyance with adding cl-style
multiple-sequence mapping operators seemed to be the interaction with support
for mapping over non-list sequences.  The current implementation just hands
off iteration to a dedicated function for each sequence type, which doesn't
work so well for multiple sequences (because each can be a different type).

One could get around this by saying that mapping operators only work
efficiently when all sequence arguments are of the same type, and in other
cases convert additional sequence types to the type of the first before
proceeding.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf