CC Mode

From my earlier message:

   I do not know whether this is deliberate or whether an
   eval-when-compile was accidentally forgotten.

I just noticed the "Don't use within `eval-when-compile'" in the
docstring of `cc-external-require'.  So the call definitely could not
be put in an `eval-when-compile'.

Sincerely,

Luc.

Luc Teirlinck <teirllm@...> writes:

> I just noticed the "Don't use within `eval-when-compile'" in the
> docstring of `cc-external-require'.  So the call definitely could not
> be put in an `eval-when-compile'.

You see my point?

Dave Love wrote:

   Luc Teirlinck <teirllm@...> writes:

   > I just noticed the "Don't use within `eval-when-compile'" in the
   > docstring of `cc-external-require'.  So the call definitely could not
   > be put in an `eval-when-compile'.

   You see my point?

I am sorry, but I believe I am missing it.  Even if that call _could_
be put in an `eval-when-compile', I still would be extremely reluctant
to do so without somebody at bug-cc-mode@... telling me it would
be OK.  Maybe cc-mode _really_ needs cl at runtime.  I do not know
cc-mode well enough to decide and you said you do not either.  So I do
not believe that we can make any further progress until somebody at
bug-cc-mode@... clarifies things.

Sincerely,

Luc.

Luc Teirlinck <teirllm@...> writes:

>    You see my point?
>
> I am sorry, but I believe I am missing it.

I meant the point about it being impenetrable.  Emacs maintainers (?)
apparently can't follow it, and it defeats features and conventions
meant to help with the sort of things involved.  (This isn't news.)

> Even if that call _could_
> be put in an `eval-when-compile', I still would be extremely reluctant
> to do so without somebody at bug-cc-mode@... telling me it would
> be OK.  Maybe cc-mode _really_ needs cl at runtime.  I do not know
> cc-mode well enough to decide and you said you do not either.

Not exactly.  It's a trivial experiment to verify, for instance, that
`c-mode' _does_ use CL functions; I just hadn't cared to.

> So I do
> not believe that we can make any further progress until somebody at
> bug-cc-mode@... clarifies things.

Dave Love wrote:

   I meant the point about it being impenetrable.  Emacs maintainers (?)
   apparently can't follow it,

If the (?) applies to me, I only am the "maintainer" of "help-at-pt.el".
But I do fix bugs in various parts of Emacs sometimes.

I do not know who can or can not follow cc-mode.  Whether one can or
can not follow something depends on the time one wants to invest.  But
to me, the relevant point is the following line in cc-mode.el:

;; Maintainer: bug-cc-mode@...

That is why I have been CC-ing this to them.

   It's a trivial experiment to verify, for instance, that `c-mode'
   _does_ use CL functions; I just hadn't cared to.

I now noticed `delete-duplicates', `intersection', `set-difference'
and `mapcan'.  There probably are others.  It is a mess.  If there are
not too many, then maybe they could be added to core Emacs.  (That is
up to Richard to decide.)

Sincerely,

Luc.

On Thu, 8 Jan 2004, Dave Love wrote:

>Luc Teirlinck <teirllm@...> writes:

>I meant the point about it [cc-external-require and friends] being
>impenetrable.  Emacs maintainers (?) apparently can't follow it, and it
>defeats features and conventions meant to help with the sort of things
>involved.  (This isn't news.)

I think the point behind these macros is to ensure that when a new
version of cc-mode is building, all the cross-references between the
cc-files.el will find the new versions, not any old versions which might
well currently be loaded.

>> Even if that call _could_ be put in an `eval-when-compile', I still
>> would be extremely reluctant to do so without somebody at
>> bug-cc-mode@... telling me it would be OK.  Maybe cc-mode _really_
>> needs cl at runtime.  I do not know cc-mode well enough to decide and
>> you said you do not either.

>Not exactly.  It's a trivial experiment to verify, for instance, that `c-mode'
>_does_ use CL functions; I just hadn't cared to.

>> So I do not believe that we can make any further progress until somebody at
>> bug-cc-mode@... clarifies things.

-- 
Alan Mackenzie (Munich, Germany)

On Thu, Jan 08, 2004 at 06:22:26PM -0600, Luc Teirlinck wrote:
> I now noticed `delete-duplicates', `intersection', `set-difference'
> and `mapcan'.  There probably are others.  It is a mess.  If there are
> not too many, then maybe they could be added to core Emacs.

mapcan, at least, should be added to core emacs I think.

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

I recompiled cc*.el and now it no longer autoloads cl.

Richard Stallman wrote:

   I recompiled cc*.el and now it no longer autoloads cl.

After making some as yet uncommitted changes to the current CVS
version?  Apparently, in the current CVS version, one can recompile,
say *% "^cc.*\.el$" in dired, any way one likes, it still loads CL at
runtime.  Maybe there is something I am missing.

Sincerely,

Luc.

I believe I have to retract an earlier (premature) conclusion that
cc-mode needs several CL functions at run time.

After taking a closer look, it now indeed would appear that cc-mode
_only_ needs the CL functions I mentioned at _compile_ time.  (They
all seem to be in c-lang-def{const,var} in cc-langs.el.)  It still
seems to remain a fact that if one bootstraps the CVS, cc-mode still
loads cl.

Sincerely,

Luc.

Luc Teirlinck <teirllm@...> wrote:

> After taking a closer look, it now indeed would appear that cc-mode
> _only_ needs the CL functions I mentioned at _compile_ time.  (They
> all seem to be in c-lang-def{const,var} in cc-langs.el.)

cc-langs is not even loaded when CC Mode is used byte compiled.
Everything in it is just an elaborate system to build various
constants at compile time.

> It still seems to remain a fact that if one bootstraps the CVS,
> cc-mode still loads cl.

Is that a problem?

On Mon, Jan 12, 2004 at 12:10:58AM +0100, Martin Stjernholm wrote:
> > It still seems to remain a fact that if one bootstraps the CVS,
> > cc-mode still loads cl.
> 
> Is that a problem?

Using cl at runtime in `basic' emacs packages has been considered `very
undesirable' for just about forever.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Miles Bader <miles@...> wrote:

> On Mon, Jan 12, 2004 at 12:10:58AM +0100, Martin Stjernholm wrote:
>> > It still seems to remain a fact that if one bootstraps the CVS,
>> > cc-mode still loads cl.
>> 
>> Is that a problem?
>
> Using cl at runtime in `basic' emacs packages has been considered `very
> undesirable' for just about forever.

I know that(*), but in this case I take it that it's a special kind of
load that only occurs initially when building from cvs?


*)  I started a discussion about it some months ago on the emacs-devel
    list but received no satisfactory justification for that policy.
    Therefore, considering that the alternative to using those basic
    functions (i.e. code duplication in some form) is obviously very
    bad, I (generally speaking) find it hard to comply with it.

Martin Stjernholm wrote:

   I know that(*), but in this case I take it that it's a special kind of
   load that only occurs initially when building from cvs?

I do:

cd /home/teirllm/emacscvsdir
cvs -z3 -d teirllm@... co .
cd emacs
make distclean
./configure --without-toolkit-scroll-bars
make bootstrap
sudo make install

Then `emacs-21.3.50 -q'

After that, visiting any file in cc-mode loads cl.

I do not completely understand what you mean with "initially".
It certainly keeps happening if I restart Emacs.

Is this what you would expect, am I doing something wrong, could there
be some omission in the make files, or is there something you
overlooked?

Sincerely,

Luc.

Martin Stjernholm wrote:

   cc-langs is not even loaded when CC Mode is used byte compiled.
   Everything in it is just an elaborate system to build various
   constants at compile time.

I noticed that later.  I should have looked at things more carefully
before making premature claims.

However, "cc-defs.el" says that it must be loaded at runtime and
contains:

(cc-external-require 'cl)

I byte-compiled that form and from looking at the .elc file, it seem
that the only purpose of that form is to tell people using Emacs 19.28
or earlier that they can forget about it.

Loading a file containing nothing but the byte-compiled form
`(cc-external-require 'cl)' does load cl.

Since people using 21.3.50 or people who will be using 21.4 or later
are definitely not using 19.28 or earlier would it be OK to replace
the (cc-external-require 'cl) in the Emacs CVS version of cc-defs.el
with a simple: (eval-when-compile (require 'cl)) (or similar)?
I checked that with this change cc-mode no longer loads cl.

Or does cc-mode really need CL functions at runtime?
Or am I actually doing something wrong?

Sincerely,

Luc.

From my earlier message:

   I byte-compiled that form and from looking at the .elc file, it seem
   that the only purpose of that form is to tell people using Emacs 19.28
   or earlier that they can forget about it.

That was yet another premature conclusion.  Sorry.

Sincerely,

Luc.

After making some as yet uncommitted changes to the current CVS
    version?  Apparently, in the current CVS version, one can recompile,
    say *% "^cc.*\.el$" in dired, any way one likes, it still loads CL at
    runtime.  Maybe there is something I am missing.

I have no changes of my own in the cc*.el files.

Miles Bader <miles@...> writes:

> mapcan, at least, should be added to core emacs I think.

For what it's worth, a TODO item suggests (or used to) providing extra
useful CL stuff at compile time so that there wouldn't need to be any
argument about it.  A few things like `caddr' are existing examples
(oft-times removed unnecessarily -- they're compiled away).

I don't think the doc makes clear which functions/macros actually can
be used safely at compile time, and the compiler warnings about CL
currently give false positives (e.g. defsetf (?) causing warnings
about gensym).

Alan Mackenzie <acm@...> writes:

> I think the point behind these macros is to ensure that when a new
> version of cc-mode is building, all the cross-references between the
> cc-files.el will find the new versions, not any old versions which might
> well currently be loaded.

Then I think it's misguided.  Files should be (batch) compiled
separately, as with other packages.  I don't see why CC should be
different; I speak from experience with Gnus and W3, amongst others.

I do:

    cd /home/teirllm/emacscvsdir
    cvs -z3 -d teirllm@... co .
    cd emacs
    make distclean
    ./configure --without-toolkit-scroll-bars
    make bootstrap
    sudo make install

    Then `emacs-21.3.50 -q'

    After that, visiting any file in cc-mode loads cl.

That looks like a problem.

If you explicitly recompile all the files cc*.el after this,
does that make the problem go away?  If so, I think the problem
is that bootstrapping doesn't compile the files properly.

> It still seems to remain a fact that if one bootstraps the CVS,
    > cc-mode still loads cl.

    Is that a problem?

If cl is loaded when a user visits a C mode file, that is a problem in
and of itself.  This is because the CL functions are not standard
parts of the defined Lisp name space.  It is legitimate for users to
define those names for other purposes.  Loading an ordinary Emacs
package should not conflict with such definitions, so the ordinary
Emacs package should not load CL at run time.

if CL is loaded during some part of bootstrapping, that's different.
That isn't a problem in itself.  If it doesn't cause some other sort
of problem, it is ok.

Richard Stallman wrote:

   If you explicitly recompile all the files cc*.el after this,
   does that make the problem go away?

No.

Sincerely,

Luc.

Dave Love <d.love@...> wrote:

> Then I think it's misguided.  Files should be (batch) compiled
> separately, as with other packages.

It's a symptom of lack of control facilities in the byte compiler, at
least up to and including Emacs 21.3 (I haven't yet investigated the
byte compiler changes in cvs). The reason for most of the cc-bytecomp
stuff is to silence various warnings about unbound variables and
functions, which would otherwise be unavoidable due to the support for
several different (X)Emacs versions. (There are apparently changes in
the cvs version of the byte compiler that make this not work as
intended since there are numerous warnings there.)

Another issue it solves (along with the load-path blobs in the
beginning of each cc-*.el file) is, as Alan said, to avoid mixing in
files from older versions of CC Mode that might reside in the
load-path. It'd be nice with a variant of `require' that only looks in
the same directory as the current file.

I'd be happy to use better tools to cope with these things if/when
they are available. Unfortunately backward compatibility doesn't allow
me to remove cc-bytecomp right away when that happens.

Of course, when CC Mode is distibuted with (X)Emacs, all of these
become non-issues, but I don't want to maintain different sources.

> I don't see why CC should be different; I speak from experience with
> Gnus and W3, amongst others.

I looked at Gnus a bit before I came up with cc-bytecomp. As far as I
remember it didn't address the issues above at all.

> From: Martin Stjernholm <mast@...>
> Date: Tue, 13 Jan 2004 02:23:30 +0100
> 
> Dave Love <d.love@...> wrote:
> 
> > Then I think it's misguided.  Files should be (batch) compiled
> > separately, as with other packages.
> 
> It's a symptom of lack of control facilities in the byte compiler, at
> least up to and including Emacs 21.3 (I haven't yet investigated the
> byte compiler changes in cvs). The reason for most of the cc-bytecomp
> stuff is to silence various warnings about unbound variables and
> functions, which would otherwise be unavoidable due to the support for
> several different (X)Emacs versions. (There are apparently changes in
> the cvs version of the byte compiler that make this not work as
> intended since there are numerous warnings there.)

Personally, warnings do not bother me as long as they aren't too many
(some packages evidently cannot be compiled without warnings without
investing a lot of effort in restructuring the code).

What does annoy me in the CVS is that apparently "make recompile" in
the lisp subdirectory doesn't DTRT for CC Mode, as afterwards I get
warnings about version mismatch between different cc-*.elc files quite
frequently.  ("make bootstrap" solves that, but I don't like to
bootstrap unnecessarily.)  I find myself in the need to manually
compile some of the cc-*.el files, which isn't easy, since the warning
message doesn't give any useful hints as to the files that need to be
recompiled.

> I looked at Gnus a bit before I came up with cc-bytecomp. As far as I
> remember it didn't address the issues above at all.

FWIW, Eshell solves similar problems nicely, although it's possible
that CC Mode is more complex.

I find myself in the need to manually
    compile some of the cc-*.el files, which isn't easy, since the warning
    message doesn't give any useful hints as to the files that need to be
    recompiled.

The usual solution method is to put the macro definitions and other
material needed for compilation into a separate file, and make the
other files require that one.  Why won't that work here?

When eliminating warnings is the goal, one method is to use
with-no-warnings in places that would get warnings you want to ignore.

Martin Stjernholm <mast@...> writes:

> I know that(*), but in this case I take it that it's a special kind of
> load that only occurs initially when building from cvs?

If building it from the development version causes problems, that's a
bug somewhere that needs to be fixed.

> *)  I started a discussion about it some months ago on the emacs-devel
>     list but received no satisfactory justification for that policy.
>     Therefore, considering that the alternative to using those basic
>     functions (i.e. code duplication in some form) is obviously very
>     bad, I (generally speaking) find it hard to comply with it.

You'll notice the duplication in CL of functions which occur in the
core with different definitions.  (I didn't find it so hard to comply
with in large packages.)

Martin Stjernholm <mast@...> writes:

> cc-langs is not even loaded when CC Mode is used byte compiled.

That's not true.

In case it's not clear, I'm talking about the (not properly
up-to-date) development source.  That's why I sent it to
emacs-pretest-bug (as I believe was correct).

Luc Teirlinck <teirllm@...> wrote:

> However, "cc-defs.el" says that it must be loaded at runtime and
> contains:
>
> (cc-external-require 'cl)

True, that will pull in cl at runtime too.

> Or does cc-mode really need CL functions at runtime?

Three cl functions are currently used in cc-defs: mapcan,
cl-macroexpand, and delete-duplicates. They are only called at compile
time with one exception: The call to delete-duplicates in
c-make-keywords-re.

If you eliminate that call (or make it legitimate), it's safe to
remove the cc-external-require form and instead put in a

  (eval-when-compile (require 'cl))

at the top of the file.

I'd prefer if delete-duplicates or something close to it were added to
the core, of course.

Dave Love <d.love@...> wrote:

> Martin Stjernholm <mast@...> writes:
>
>> cc-langs is not even loaded when CC Mode is used byte compiled.
>
> That's not true.

It is indeed, assuming the version is 5.30 or any of the later patch
releases. But perhaps you've encountered a bug - please specify which
version you're using and what you do to cause this incorrect load of
cc-langs.

Richard Stallman <rms@...> writes:

> When eliminating warnings is the goal, one method is to use
> with-no-warnings in places that would get warnings you want to ignore.

That seems to be something rather new and not helpful for
cross-platform stuff per se.  (I'm surprised it's really necessary.)

Martin Stjernholm <mast@...> writes:

> It's a symptom of lack of control facilities in the byte compiler, at
> least up to and including Emacs 21.3 (I haven't yet investigated the
> byte compiler changes in cvs).

I can't remember what went in where, but I think the features in the
development version of the compiler are sufficient for this (modulo
spurious warnings about CL functions that I don't understand).  I put
in what I thought was necessary/sufficient from experience.

> (There are apparently changes in
> the cvs version of the byte compiler that make this not work as
> intended since there are numerous warnings there.)

That's the sort of thing I mean about working against the compiler.
There have been a fair number of bugs in Gnus &c due to silencing
errors which were meaningful.

> I looked at Gnus a bit before I came up with cc-bytecomp. As far as I
> remember it didn't address the issues above at all.

I said I spoke from experience with it, and I can't see that it needs
anything more than understanding and care from developers (who
unfortunately don't seem to be much interested in what's shipped with
Emacs).

I think the thing about using the wrong path is a non-issue.  In the
Gnus files I had time to work on some months ago, as far as I remember
I cleanly eliminated all the compiler warnings when using the
then-development Emacs (without any of its ill-advised build stuff).
Since XEmacs doesn't appear to have such facilities, you guard use of
XEmacs stuff rather than Emacs, of course.

Martin Stjernholm wrote:

   > You'll notice the duplication in CL of functions which occur in the
   > core with different definitions.

   I've noticed two such duplications: `dotimes' and `dolist'.

In addition, cl redefines `macroexpand' as an alias for
`cl-macroexpand'.  I do not know of any problems caused by these three
redefinitions, unless one tries to "unload" cl, which would apparently
give problems for several unrelated reasons too.

As a consequence of a cosmetic change I made (defining `declare' as a
trivial macro in core Emacs, as it already was in cl), `declare' is
now a fourth element of the list.  cl's redefinition of that one
should be completely harmless.  (The two definitions differ only at
compile time and the treatment of `declare' in core Emacs and cl is
now closer than it used to be).

There may be other redefinitions I have missed.  The redefinition of
`macroexpand' is hidden somewhere inside a defvar and there may be
other instances like that.

Sincerely,

Luc.

Martin Stjernholm wrote:

   Three cl functions are currently used in cc-defs: mapcan,
   cl-macroexpand, and delete-duplicates. They are only called at compile
   time with one exception: The call to delete-duplicates in
   c-make-keywords-re.

   If you eliminate that call (or make it legitimate), it's safe to
   remove the cc-external-require form and instead put in a

     (eval-when-compile (require 'cl))

   at the top of the file.

Are we talking about the same version of "cc-defs.el"?  The current
Emacs CVS version of `c-make-keywords-re' in "cc-defs.el" does not
appear to contain any call to `delete-duplicates'.  Instead it
contains the following substitute code for that function:
  
  (let (unique)
    (dolist (elt list)
      (unless (member elt unique)
      (push elt unique)))
    (setq list unique))

Sincerely,

Luc.

Martin Stjernholm <mast@...> writes:
> Three cl functions are currently used in cc-defs: mapcan,
> cl-macroexpand, and delete-duplicates. They are only called at compile
> time with one exception: The call to delete-duplicates in
> c-make-keywords-re.

I'd like to add mapcan to the core.

`delete-duplicates' has a typical problem of many cl functions: it uses
keyword arguments.  Maybe we could add a simpler version of it to the
core which would be `upward compatible' with the cl version (so that cl
could redefine it upon being loaded without screwing up `native' users).

Why use `cl-macroexpand' instead of just `macroexpand'?

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

Dave Love <d.love@...> wrote:

> Martin Stjernholm <mast@...> writes:
>
>> I know that(*), but in this case I take it that it's a special kind of
>> load that only occurs initially when building from cvs?
>
> If building it from the development version causes problems, that's a
> bug somewhere that needs to be fixed.

Note "only" and "initially" - it follows that my propositions was that
the problem would not reoccur at later loads. Luc has since clarified
that that isn't the case, so it is indeed a problem wrt that policy.

> You'll notice the duplication in CL of functions which occur in the
> core with different definitions.

I've noticed two such duplications: `dotimes' and `dolist'. They
obviously have been taken from cl-macs.el and moved to the core, and
in the process they've been rewritten to not use other cl constructs
internally. Afaics they are still semantically identical so they
aren't problematic.

Are you referring to something else I've missed?

> (I didn't find it so hard to comply with in large packages.)

Perhaps you haven't had the need to use functions like
`delete-duplicates' and `cl-macroexpand'.

In addition, cl redefines `macroexpand' as an alias for
    `cl-macroexpand'.  I do not know of any problems caused by these three
    redefinitions, unless one tries to "unload" cl, which would apparently
    give problems for several unrelated reasons too.

I don't think we need to worry about this.

I gave CL an unload hook that gives an error.  That will make it
clear that unloading CL is unsupported, and that prevent Emacs from
trying to unload it and messing it up.

Luc Teirlinck <teirllm@...> wrote:

> Are we talking about the same version of "cc-defs.el"?  The current
> Emacs CVS version of `c-make-keywords-re' in "cc-defs.el" does not
> appear to contain any call to `delete-duplicates'.  Instead it
> contains the following substitute code for that function:
/.../

Ah, I'm sorry, I forgot to check the Emacs sources when I said it did.
Apparently someone has already located and made a workaround in Emacs
for that. Then it should be safe to change the require of cl to
compile time only.

Martin Stjernholm <mast@...> writes:
>> That's not true.
>
> It is indeed, assuming the version is 5.30 or any of the later patch
> releases. But perhaps you've encountered a bug -

I know it's a bug, whatever the cause.  That's why I reported the fact
to the appropriate bug address.  In most cases like that, I'd probably
have supplied a fix.

> please specify which version

As I said in the report, it's a recent version from Emacs CVS.  As far
as I could tell at the time, it was the most recent.

> you're using and what you do to cause this incorrect load of
> cc-langs.

Executing `c-mode' as the first command in `emacs -q'.

Martin Stjernholm <mast@...> writes:

> Note "only" and "initially" - it follows that my propositions was
> that the problem would not reoccur at later loads.  Luc has since
> clarified that that isn't the case, so it is indeed a problem wrt
> that policy.

I don't understand this, but it doesn't seem to be getting anywhere.

> I've noticed two such duplications: `dotimes' and `dolist'. They
> obviously have been taken from cl-macs.el and moved to the core, and
> in the process they've been rewritten to not use other cl constructs
> internally. Afaics they are still semantically identical so they
> aren't problematic.

Actually, they aren't, which is why they're still in CL.

> Perhaps you haven't had the need to use functions like
> `delete-duplicates' and `cl-macroexpand'.

1999-12-04  Dave Love  <fx@...>

	* mm-util.el (mm-delete-duplicates): New function.
	(mm-write-region): Use it.

I certainly wouldn't use `cl-macroexpand' since it's an internal
function, and I've faced problems with those in the past.
`macroexpand' is one of the things CL clobbers.

I think there's evidence in changelogs that I'm not talking through my
hat about this.

Martin Stjernholm <mast@...> writes:

> I'd prefer if delete-duplicates or something close to it were added to
> the core, of course.

For what it's worth, that's probably the one I thought most useful but
I never got round to getting it in.

Dave Love wrote:

   > please specify which version

   As I said in the report, it's a recent version from Emacs CVS.  As far
   as I could tell at the time, it was the most recent.

You could execute (emacs-version):

ELISP> (emacs-version)
"GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, X toolkit)\n of 2004-01-16 on
swt40.swt.com"

   > you're using and what you do to cause this incorrect load of
   > cc-langs.

   Executing `c-mode' as the first command in `emacs -q'.

With _today's_ CVS I can not reproduce the bug you describe:

emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &
M-x c-mode
M-: (featurep 'cc-langs)

Result: nil.

Sincerely,

Luc.

From my previous message:

      > please specify which version

      As I said in the report, it's a recent version from Emacs CVS.  As far
      as I could tell at the time, it was the most recent.

   You could execute (emacs-version):

Sorry, I forgot that you were talking about the _cc-mode_ version.
Anyway, the really relevant fact is that with the version of cc-mode
included in today's CVS, I can not reproduce the bug you describe.

Sincerely,

Luc.

Dave Love wrote:

   Martin Stjernholm <mast@...> writes:

   > Note "only" and "initially" - it follows that my propositions was
   > that the problem would not reoccur at later loads.  Luc has since
   > clarified that that isn't the case, so it is indeed a problem wrt
   > that policy.

   I don't understand this, but it doesn't seem to be getting anywhere.

I believe that we are not only getting somewhere, I believe the problem
is solved, unless the solution would turn out to cause other
problems.  I have been using a one line change in cc-defs.el for some
time now, without cl being loaded by cc-mode and without any other
apparent problems.  I do not use every single aspect of cc-mode
however and I was waiting for Martin's OK before committing the change.

Martin today said the change should be safe and I committed it.  It is
a trivial one line change and should be easy to undo if it would turn
out to cause problems.

Sincerely,

Luc.

From my previous message:

   With _today's_ CVS I can not reproduce the bug you describe:

   emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &
   M-x c-mode
   M-: (featurep 'cc-langs)

   Result: nil.

I should clarify that this was _before_ my change to cc-defs.el.
After that change, not only (featurep 'cc-langs) but also 
(featurep 'cl) returns nil.

Sincerely,

Luc.

Miles Bader <miles@...> wrote:

> `delete-duplicates' has a typical problem of many cl functions: it uses
> keyword arguments.  Maybe we could add a simpler version of it to the
> core which would be `upward compatible' with the cl version (so that cl
> could redefine it upon being loaded without screwing up `native' users).

If the problem with keyword arguments is runtime overhead, it ought to
be possible to make a macro package that translate such keyword
arguments to position based argument passing at compile time.

> Why use `cl-macroexpand' instead of just `macroexpand'?

I'm sorry, I meant cl-macroexpand-all.

Dave Love <d.love@...> wrote:

>> I've noticed two such duplications: `dotimes' and `dolist'. They
>> obviously have been taken from cl-macs.el and moved to the core, and
>> in the process they've been rewritten to not use other cl constructs
>> internally. Afaics they are still semantically identical so they
>> aren't problematic.
>
> Actually, they aren't, which is why they're still in CL.

Quite. Looks like they are extended by cl to work better with other cl
constructs. In code that doesn't use cl, that extension ought not have
any effect, and so it's not a problem. Correct?

> 1999-12-04  Dave Love  <fx@...>
>
> 	* mm-util.el (mm-delete-duplicates): New function.
> 	(mm-write-region): Use it.

Given the current discussion, I assume the reason for that was the
policy regarding the cl package and not anything else.

That is the thing I definitely don't want to do. It's code duplication
and bad programming for a reasons so obvious I don't think I have to
elaborate on them. The fact that the cl policy forces code like that
makes it disruptive to an extent that is far out of proportion.

So if it comes to a choice between that and disregarding the policy, I
choose to disregard the policy. (That doesn't imply that I will in any
way obstruct patches made to CC Mode in Emacs to comply to it however,
but I won't do them myself and I won't maintain them.) Note that I
have made a serious attempt to understand the reasons for the policy
(see the thread on emacs-devel last autumn), and I would heed it if
there were any that were sufficiently compelling.

> I certainly wouldn't use `cl-macroexpand' since it's an internal
> function, and I've faced problems with those in the past.

I can see no signs that cl-macroexpand would be an internal function.
How does it show?

Anyway, I mentioned the wrong function; I actually meant
cl-macroexpand-all.

> `macroexpand' is one of the things CL clobbers.

If that's a problem then I suggest that cl is restructured so that
there is a package, say cl-safe, which can be required at runtime and
which doesn't do anything like that. (I've suggested that before.)

> I think there's evidence in changelogs that I'm not talking through my
> hat about this.

I haven't suggested that you are. I'm sorry if I gave that impression.

On Sat, Jan 17, 2004 at 01:17:38PM +0100, Martin Stjernholm wrote:
> > `delete-duplicates' has a typical problem of many cl functions: it uses
> > keyword arguments.  Maybe we could add a simpler version of it to the
> > core which would be `upward compatible' with the cl version (so that cl
> > could redefine it upon being loaded without screwing up `native' users).
> 
> If the problem with keyword arguments is runtime overhead, it ought to
> be possible to make a macro package that translate such keyword
> arguments to position based argument passing at compile time.

Perhaps; I think there are practical impediments to such an approach in
general though (notably it requires the function definition be known when
compiling callers).

However, besides I'd be very reluctant to start using keyword arguments in
the `common lisp manner' simply because it breaks stylistically with elisp.
In elisp keyword arguments are generally used only when they there is a wide
range of possible arguments (like in set-face-attribute), but in common-lisp
they are often used in situations where emacs uses optional arguments.

> I'm sorry, I meant cl-macroexpand-all.

Hmmm, I've got a standalone non-cl version of macroexpand-all that I'd like
to merge at some point anyway... [in my lexical-binding emacs, the compiler
uses macroexpand-all at an early stage instead of macroexpanding each form as
it is compiled.]

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

Dave Love <d.love@...> wrote:

> I know it's a bug, whatever the cause.  That's why I reported the fact
> to the appropriate bug address.

I haven't seen it so it must have gotten lost along the way. I see
reports regarding CC Mode that are sent to bug-cc-mode@.... If
maintainers of other software stipulate other addresses then someone
reading those will need to forward the reports to ensure they aren't
missed.

>> you're using and what you do to cause this incorrect load of
>> cc-langs.
>
> Executing `c-mode' as the first command in `emacs -q'.

I'm sorry, but I can't reproduce it.

Eli Zaretskii <eliz@...> wrote:

> What does annoy me in the CVS is that apparently "make recompile" in
> the lisp subdirectory doesn't DTRT for CC Mode, as afterwards I get
> warnings about version mismatch between different cc-*.elc files quite
> frequently.

I've made a couple simple attempts to trig something like that, but
without success. Do you think you could provide a recipe to reproduce
it? What do the warnings say?

>> I looked at Gnus a bit before I came up with cc-bytecomp. As far as I
>> remember it didn't address the issues above at all.
>
> FWIW, Eshell solves similar problems nicely, although it's possible
> that CC Mode is more complex.

Are you referring to esh-maint.el?

Richard Stallman <rms@...> wrote:

>       I find myself in the need to manually
>     compile some of the cc-*.el files, which isn't easy, since the warning
>     message doesn't give any useful hints as to the files that need to be
>     recompiled.
>
> The usual solution method is to put the macro definitions and other
> material needed for compilation into a separate file, and make the
> other files require that one.  Why won't that work here?

It would work when distributed with Emacs, but might not when users
download and install the standalone dist of CC Mode. And as I said
before, I want to keep a single source as far as possible. Anyway, I
don't understand the connection between that and the problem Eli
Zaretskii describes.

> When eliminating warnings is the goal, one method is to use
> with-no-warnings in places that would get warnings you want to ignore.

Good to know, but that helper does not work very well as a replacement
for the cc-bytecomp stuff, unfortunately. cc-bytecomp lets the user
specify functions and variables for which no warnings should be
generated if they aren't bound. To replace that with with-no-warnings,
it's necessary to change the code at every location where the
functions and variables are used.

> From: Martin Stjernholm <mast@...>
> Date: Sat, 17 Jan 2004 14:03:43 +0100
> 
> > What does annoy me in the CVS is that apparently "make recompile" in
> > the lisp subdirectory doesn't DTRT for CC Mode, as afterwards I get
> > warnings about version mismatch between different cc-*.elc files quite
> > frequently.
> 
> I've made a couple simple attempts to trig something like that, but
> without success. Do you think you could provide a recipe to reproduce
> it?

The recipe is very simple:

  . Build Emacs with these commands:

     ./configure
     make
     cd lisp && make recompile EMACS=../src/emacs
     make

  . Start Emacs with "emacs -q" and visit any C file.


> What do the warnings say?

They say

   c-mode compiled with CC Mode 5.30.7 but loaded with 5.30.8 - evaluating language constants from source

More details from the *Messages* buffer:

  Loading cc-mode...
  Loading cc-langs...done
  Loading cc-mode...done
  c-mode compiled with CC Mode 5.30.7 but loaded with 5.30.8 - evaluating language constants from source
  Loading cl-extra...done
  Loading cl-seq...done
  Loading vc-cvs...done

Note that "make recompile" in the lisp/ directory does not recompile
any files even after this warning is displayed.  So obviously
lisp/Makefile doesn't know about whatever hidden dependency that
triggers this problem.

In case it matters, the last ChangeLog entry for cc-mode files I have
on this system is from 2003-11-16.  AFAIR, such warnings happen every
time there's some major update of the cc-mode files in the CVS
(probably every time c-version changes).

HTH

> From: Martin Stjernholm <mast@...>
> Date: Sat, 17 Jan 2004 14:03:43 +0100
> 
> >> I looked at Gnus a bit before I came up with cc-bytecomp. As far as I
> >> remember it didn't address the issues above at all.
> >
> > FWIW, Eshell solves similar problems nicely, although it's possible
> > that CC Mode is more complex.
> 
> Are you referring to esh-maint.el?

Maybe, I really don't know.  What I do know that Eshell has similar
problems of interdependency, one can see that by naively compiling a
random Eshell file manually.  And yet "make recompile" somehow manages
to compile all the modified files so that no warnings are seen later.

I don't want to put keyword arguments into the list manipulating
functions of Emacs Lisp.  I think it goes against the spirit of Lisp.
I felt that way, to some extent, when Common Lisp was designed.
In any case, it is very much against the spirit of Emacs Lisp.
In some obscure functions that must have complex args, it is ok,
but I'd rather avoid it where there is no need for it,

If the existence of multiple equivalent functions bothers people,
I would rather install a function delq-duplicates that compares
using eq.  That fits the spirit of Emacs Lisp.

Richard Stallman wrote:

   If the existence of multiple equivalent functions bothers people,
   I would rather install a function delq-duplicates that compares
   using eq.  That fits the spirit of Emacs Lisp.

I have no strong personal opinions on this.  Just trying to float some
ideas around:

I personally believe that using `equal' as test is more useful than
`eq'.  All current uses I am aware of in the Emacs code use `equal' as
test.  I see two possibilities:

1. Use a function of one argument, the list, and `equal' as test.

2. Use a function of two arguments, one required, the list, and one
   optional, the test, defaulting to `equal'.

Either way, we could use a name such as, say, `delete-repeats' to make
clear that the function is not identical with the CL function
`delete-duplicates', and avoid a name clash.

If we go for (1), then maybe we could just rename
`mm-delete-duplicates', rewrite its docstring, and move it from
mm-util.el into subr.el or some similar place:

(defun mm-delete-duplicates (list)
  "Simple substitute for CL `delete-duplicates', testing with `equal'."
  (let (result head)
    (while list
      (setq head (car list))
      (setq list (delete head list))
      (setq result (cons head result)))
    (nreverse result)))

Some people might stylistically prefer:

(push head result) over: (setq result (cons head result)),

and maybe we should make that change, but that is just an unimportant
detail.

Even (2) should produce a function whose code is substantially simpler
and more transparent than `cl-delete-duplicates'.

Sincerely,

Luc.

> Date: Sat, 17 Jan 2004 21:55:29 -0600 (CST)
> From: Luc Teirlinck <teirllm@...>
> 
> 1. Use a function of one argument, the list, and `equal' as test.
> 
> 2. Use a function of two arguments, one required, the list, and one
>    optional, the test, defaulting to `equal'.

I'm far from regarding myself as someone who feels the spirit of
Emacs Lisp, but I like the second alternative better.

> Either way, we could use a name such as, say, `delete-repeats' to make
> clear that the function is not identical with the CL function
> `delete-duplicates', and avoid a name clash.

How about `delete-dups'?

I personally believe that using `equal' as test is more useful than
    `eq'.  All current uses I am aware of in the Emacs code use `equal' as
    test.

We could add a function delete-duplicates that takes just one argument
and uses equal to compare.  Loading cl would extend this, just as
it extends dolist and dotimes.

Or we could call it delete-repeats.

Rather than make it accept a comparison function as argument,
I'd prefer to continue the distinction between delq and delete.
We could add delq-repeats if we ever need it.
This is more consistent with the rest of Emacs Lisp.

Richard Stallman <rms@...> wrote:

> Or we could call it delete-repeats.

I think something like `delete-dups' would be a better name. I tend to
interpret `delete-repeats' as a function that only would delete
duplicates when they occur directly after each other, i.e. when the
same element is "repeated".

Richard Stallman wrote:

   We could add a function delete-duplicates that takes just one argument
   and uses equal to compare.  Loading cl would extend this, just as
   it extends dolist and dotimes.

   Or we could call it delete-repeats.

What about the following patches to subr.el and mm-util.el?
Essentially, they contain no new code.  I just relocated
`mm-delete-duplicates', renamed it and gave it a new docstring.  In as
far as the name is concerned, we can not use `delete-duplicates',
because it uses different defaults (see below).  I personally prefer
`delete-repeats', but since two people have already said that they
prefer `delete-dups', I have used that name in my patches.

If desired, I could commit the two patches and write entries for the
NEWS and the Elisp manual.

(delete-dups list) would essentially be equivalent to:
(delete-duplicates list :test 'equal :from-end t) where LIST has to
be a list.  The normal CL defaults are 'eql for :test and nil for
:from-end.

The differences are:

1.  LIST must be a list, whereas the cl version allows any sequence.  All
    uses I know of use lists.

2. Uses 'equal to compare instead of 'eql.  All uses I am aware of use
   'equal.

3. The new (actually "renamed") function keeps the first element in a
   set of equal elements, the cl version keeps, by default the last.
   In all examples I know of, the order does not matter _anyway_, but
   if it would, then systematically keeping the _first_ element seems
   to come closer to the intuitive idea of removing duplicates while
   keeping the original order and would appear likely to be the wanted
   behavior in the majority of cases.

Diffs:

===File ~/subr-diff=========================================
*** subr.el.~1.376.~	Thu Jan 15 18:54:50 2004
--- subr.el	Sun Jan 18 17:57:12 2004
***************
*** 209,214 ****
--- 209,227 ----
  	   (if (> n 0) (setcdr (nthcdr (- (1- m) n) x) nil))
  	   x))))
  
+ (defun delete-dups (list)
+   "Destructively return LIST, with `equal' duplicates removed.
+ LIST must be a proper list.  The value of LIST after a call to
+ this function is undefined.  Use \(setq LIST (delete-dups LIST))
+ if you want to store the return value in LIST.  Of several
+ `equal' occurrences of an element in LIST, the first one is kept."
+   (let (result head)
+     (while list
+       (setq head (car list))
+       (setq list (delete head list))
+       (push head result))
+     (nreverse result)))
+ 
  (defun number-sequence (from &optional to inc)
    "Return a sequence of numbers from FROM to TO (both inclusive) as a list.
  INC is the increment used between numbers in the sequence and defaults to 1.
============================================================

===File ~/mm-util-diff======================================
*** mm-util.el.~1.29.~	Sat Jan 17 21:04:12 2004
--- mm-util.el	Sun Jan 18 17:18:36 2004
***************
*** 453,466 ****
      ;; This is for XEmacs.
      (mm-mule-charset-to-mime-charset charset)))
  
! (defun mm-delete-duplicates (list)
!   "Simple substitute for CL `delete-duplicates', testing with `equal'."
!   (let (result head)
!     (while list
!       (setq head (car list))
!       (setq list (delete head list))
!       (setq result (cons head result)))
!     (nreverse result)))
  
  ;; It's not clear whether this is supposed to mean the global or local
  ;; setting.  I think it's used inconsistently.  -- fx
--- 453,459 ----
      ;; This is for XEmacs.
      (mm-mule-charset-to-mime-charset charset)))
  
! (defalias 'mm-delete-duplicates 'delete-dups)
  
  ;; It's not clear whether this is supposed to mean the global or local
  ;; setting.  I think it's used inconsistently.  -- fx
============================================================

There might be a problem with my previous proposal for `delete-dups'.
The function I proposed to copy into subr.el conses up a _new_ list.
That somehow might go against the "spirit" of `delete-dups' (one might
quite as well implement a non-destructive `remove-dups' in that case).
I believe `delete-dups' is supposed to scavenge on the conses of LIST.
The following alternate version does exactly that.  It is not
completely equivalent to the prior version, but instead to:
(delete-duplicates list :test 'equal) with :from-end being nil.  That
is, the last instead of the first of each set of `equal' elements is
kept.  In all instances I am aware of, the order does not matter
anyway.  I could install either version.  I would still double-check
the alternate version more carefully if we decide to go for it.

Alternate version:

(defun delete-dups (list)
    "Destructively return LIST, with `equal' duplicates removed.
LIST must be a proper list.  The value of LIST after a call to
this function is undefined.  Use \(setq LIST (delete-dups LIST))
if you want to store the return value in LIST.  Of several
`equal' occurrences of an element in LIST, the last one is kept."
  (while (member (car list) (cdr list))
    (pop list))
  (let ((tail list))
    (while tail
      (while (member (cadr tail) (cddr tail))
	(setcdr tail (cddr tail)))
      (pop tail)))
  list)

I think something like `delete-dups' would be a better name.

Ok.

I believe `delete-dups' is supposed to scavenge on the conses of LIST.
    The following alternate version does exactly that.

Please install your change.
Thanks.

Please change etc/NEWS also.

I installed the non-consing version of `delete-dups' and added an item
to the NEWS.  I did not however make the change to mm-util.el making
`mm-delete-duplicates' an alias for `delete-dups'.  There is, as I
pointed out, a subtle difference between the two functions:
`delete-dups' keeps the last occurrence of each element,
`mm-delete-duplicates' the first.  I doubt that the order makes any
difference whatsoever, but I will leave the decision on whether to
install the defalias up to Dave, who knows the details.

Sincerely,

Luc.

Luc Teirlinck <teirllm@...> writes:

> You could execute (emacs-version):

That wouldn't be useful -- study its implementation.  I've already
given all the available relevant information.

I don't want to discourage people contributing, but I'm afraid
responding to bug reports like this isn't helpful.  With me it just
wastes time, but others will think replies are authoritative.

> With _today's_ CVS I can not reproduce the bug you describe:
>
> emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &
> M-x c-mode
> M-: (featurep 'cc-langs)

But the subject is CL.  I don't know whether it's wrong for anything
else to be loaded.

Luc Teirlinck <teirllm@...> writes:

> I believe that we are not only getting somewhere, I believe the problem
> is solved, unless the solution would turn out to cause other
> problems.

I'm glad if a trivial part of the problem is fixed, but the most
important of the commonly-accepted questions about bug fixes is

3. How can we prevent it happening again?

I was referring to the maintenance problem, which I assume experienced
maintainers will understand.

Martin Stjernholm <mast@...> writes:

> Quite. Looks like they are extended by cl to work better with other cl
> constructs.

They basically obey the Common Lisp specification.

> That is the thing I definitely don't want to do. It's code
> duplication

As far as I remember, that didn't actually duplicate CL code.  It's
the simple case that's normally wanted.
 
> and bad programming for a reasons so obvious I don't think I have to
> elaborate on them.

_I'm_ clearly not the world's best programmer, and I'm not responsible
for the policy but I have actually maintained this stuff and things
affected by it.  It's not obvious to me it deserves insulting remarks.

> The fact that the cl policy forces code like that
> makes it disruptive to an extent that is far out of proportion.

No, this reaction is out of proportion.  If it's clear it's
sufficiently useful to have something in the Emacs core, it will be
put there.  (At least, that's how it was when I did it.)

> I can see no signs that cl-macroexpand would be an internal function.
> How does it show?

The prefix, and the fact that it's not documented.

Luc Teirlinck <teirllm@...> writes:

> I installed the non-consing version of `delete-dups' and added an item
> to the NEWS.

[That seems a rather unfortunate name/implementation to me.]

> I did not however make the change to mm-util.el making
> `mm-delete-duplicates' an alias for `delete-dups'.

You certainly can't do that unconditionally, and it's not worth doing
at all.

> I doubt that the order makes any
> difference whatsoever, but I will leave the decision on whether to
> install the defalias up to Dave, who knows the details.

No, I installed it long ago for a specific purpose and I don't know
how it's used now.  I only mentioned it to demonstrate I wasn't
talking through my hat.

Martin Stjernholm <mast@...> writes:

> I see reports regarding CC Mode that are sent to
> bug-cc-mode@.... If maintainers of other software stipulate
> other addresses then someone reading those will need to forward the
> reports to ensure they aren't missed.

Exactly, if they see fit.  Someone who apparently isn't a maintainer
forwarded it.

> I'm sorry, but I can't reproduce it.

I don't understand how that could happen with the version I was
reporting on.  Anyway, you're reported to have approved a fix!  This
is pretty confusing even to an expert, and there's clearly a
maintenance problem.

Dave Love wrote:

   That wouldn't be useful -- study its implementation.  I've already
   given all the available relevant information.

No, you gave _incorrect_ information.  You claimed that executing
`c-mode' as the first command in `emacs -q' would load cc-langs.  This
would be a bug in cc-mode, because it is not supposed to do that.
Your recipe does _not_ load cc-langs.  But, of course, Martin and I
are supposed to be psychics and _know_ that when you say cc-langs you
actually mean cl.

Please try to file _accurate_ bug reports and do not assume that
people are psychics.

Sincerely,

Luc.

Dave Love wrote (in response to Martin Stjernholm):
   
   > I'm sorry, but I can't reproduce it.

   I don't understand how that could happen with the version I was
   reporting on.  Anyway, you're reported to have approved a fix!

Martin nor me could reproduce the bug you described about cc-langs
being loaded.  We now know that to you cc-langs is just an alias for
cl, but neither of us knew that at the time.  Martin said it was OK to
make a change in cc-defs.el to prevent _cl_ from being loaded.  There
was no need to make any change to prevent cc-langs from being loaded
at runtime, because that did not happen anyway.

   This is pretty confusing even to an expert, and there's clearly a
   maintenance problem.

Your logic here beats me.

Sincerely,

Luc.

Dave Love wrote:

   3. How can we prevent it happening again?

By trying to convince Martin that his concerns for avoiding code
duplication are _not_ incompatible with Richard's concerns and can be
achieved by slowly adding some CL-type functionality in ways that are
philosophically compatible with Elisp, rather than adding tons of cl
functions all at once.  I definitely believe that is the case and
would wish that Martin would try that out rather than sticking with
his current position.

   I was referring to the maintenance problem, which I assume experienced
   maintainers will understand.

And by avoiding silliness like this.  I personally would wish that
Martin would change his mind about not supporting the convention of
not loading cl at runtime.  But referring to philosophical differences
as incompetent maintenance is factually incorrect and outright silly.
I am a user of cc-mode.  It is a very high quality program with
remarkably little bugs for its complexity.  It is an important asset
to the Free Software movement.  You seem to claim that any
"experienced maintainer" will agree with you that there are
maintenance problems with cc-mode.  Have you found _any_ of those
"experienced maintainers" yet?

Sincerely,

Luc.

Luc Teirlinck <teirllm@...> writes:

> Dave Love wrote:
>
>    That wouldn't be useful -- study its implementation.  I've already
>    given all the available relevant information.
>
> No, you gave _incorrect_ information.  You claimed that executing
> `c-mode' as the first command in `emacs -q' would load cc-langs.
> This would be a bug in cc-mode, because it is not supposed to do
> that.

Firstly the reply is out of its context of version information, and
secondly I was reporting an experimental datum concerning cc-langs
which was explicitly confirmed by someone else with more detail.

> Your recipe does _not_ load cc-langs.

Maybe it doesn't _now_ -- I haven't checked.  It did.

> But, of course, Martin and I
> are supposed to be psychics and _know_ that when you say cc-langs you
> actually mean cl.

Because I don't.  This is invention.  If I made a mistake, I would
apologize for the confusion.  (Look at the subject of this thread if
you think I wasn't complaining about cl.)

> Please try to file _accurate_ bug reports and do not assume that
> people are psychics.

  (require 'cc-mode) is enough to get
  
  (featurep 'cl)
    => t

was inaccurate how, exactly?  Anyhow, you should take up the matter
with eliz too if you're only concerned with cc-langs.  See
<2914-Sat17Jan2004193932+0200-eliz@...>.  He actually noticed a
relevant message I didn't.

Please don't do a disservice to Emacs by taking this sort of insulting
line with people making proper bug reports.  I know _from long
maintenance experience_ that it's difficult enough to get them in the
first place.

Luc Teirlinck <teirllm@...> writes:

> By trying to convince Martin that his concerns for avoiding code
> duplication are _not_ incompatible with Richard's concerns and can be
> achieved by slowly adding some CL-type functionality in ways that are
> philosophically compatible with Elisp, rather than adding tons of cl
> functions all at once.

The point is _not_ about CL per se, though I've already pointed to the
TODO item I wrote which could finesse the issue.  If it was, I'd just
have provided a fix.

> But referring to philosophical differences as incompetent
> maintenance is factually incorrect and outright silly.

It is `factually incorrect' that I did so.  Kindly stop inventing
things.

Dave Love wrote:

   > Your recipe does _not_ load cc-langs.

   Maybe it doesn't _now_ -- I haven't checked.  It did.

But in a prior message you wrote:

   > With _today's_ CVS I can not reproduce the bug you describe:
   >
   > emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &
   > M-x c-mode
   > M-: (featurep 'cc-langs)

   But the subject is CL.  I don't know whether it's wrong for anything
   else to be loaded.

Thereby suggesting that you meant cl instead of cc-langs, whereas I
was responding to your claim about loading cc-langs.  That was what I
reacted to.  I never claimed your initial bug report about loading
_cl_ was inaccurate.  Clearly the information you gave in the second
bug report (about loading cc-langs) was insufficient to allow either
me or Martin to reproduce the bug.  Maybe it depends on the details of
how things are compiled, which you did not provide.

   > But referring to philosophical differences as incompetent
   > maintenance is factually incorrect and outright silly.

   It is `factually incorrect' that I did so.  Kindly stop inventing
   things.

That is how I understood the sentence I quoted.  I am sorry to have
misunderstood you.  I am glad that is not what you meant.  But you
talk in very cryptic terms and understanding you correctly is
difficult.  I still do not understand what "maintenance problem" you
are talking about, but maybe somebody else eventually will.

Sincerely,

Luc.

Dave Love wrote:

   > But referring to philosophical differences as incompetent
   > maintenance is factually incorrect and outright silly.

   It is `factually incorrect' that I did so.  Kindly stop inventing
   things.

On this issue ypu are right.  Philosophical differences can cause
maintenance problems, without being due to incompetence.  You did not
use the word incompetence.  Sorry for inadvertently reading things
into your statement that were not in there.

Sincerely,

Luc.

No, this reaction is out of proportion.  If it's clear it's
    sufficiently useful to have something in the Emacs core, it will be
    put there.

Yes.  If some feature in CL is useful in many packages, nowadays our
policy is to put it in standard Emacs.  We have made around a dozen
CL functions standard in the past few years.

"Eli Zaretskii" <eliz@...> wrote:

>> > What does annoy me in the CVS is that apparently "make recompile" in
>> > the lisp subdirectory doesn't DTRT for CC Mode, as afterwards I get
>> > warnings about version mismatch between different cc-*.elc files quite
>> > frequently.

A way to trig that is to compile the lisp files, change the c-version
string in cc-defs.el and then do "make recompile". As you suspect, the
problem was that there are dependencies that the make file didn't know
about. It's the compile time macro expansions in the language variable
system that causes it. I've now committed a kludge to lisp/Makefile.in
to cope with it.

> From: Martin Stjernholm <mast@...>
> Date: Mon, 09 Feb 2004 01:55:54 +0100
> 
> It's the compile time macro expansions in the language variable
> system that causes it. I've now committed a kludge to lisp/Makefile.in
> to cope with it.

Thanks!

Dave Love <d.love@...> writes:
>Luc Teirlinck <teirllm@...> writes:
>> I installed the non-consing version of `delete-dups' and added an item
>> to the NEWS.
>
>[That seems a rather unfortunate name/implementation to me.]

I'll withhold opinion on the name, but as for the implementation...

In keeping with the earlier suggestion that it's better to keep
the first of any duplicated elements rather than the last, I
propose the following implementation, which satisfies that
requirement and is also simpler.  (Note that since the first
element of the list is always a "keeper", the modified list is
always the same as the return value, and it's no longer strictly
necessary for the caller to wrap this in a setq.)

(defun delete-dups (list)
    "Destructively return LIST, with `equal' duplicates removed.
LIST must be a proper list.  Of several `equal' occurrences of an
element in LIST, the first one is kept."
  (let ((tail list))
    (while tail
      (setcdr tail (delete (car tail) (cdr tail)))
      (setq tail (cdr tail))))
  list)

On Tue, Feb 10, 2004 at 09:31:33PM -0500, Karl Heuer wrote:
> >> I installed the non-consing version of `delete-dups' and added an item
> >> to the NEWS.
> >
> >[That seems a rather unfortunate name/implementation to me.]
> 
> I'll withhold opinion on the name, but as for the implementation...

What do people think the name should be?

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Karl Heuer wrote:

   In keeping with the earlier suggestion that it's better to keep
   the first of any duplicated elements rather than the last, I
   propose the following implementation, which satisfies that
   requirement and is also simpler.  (Note that since the first
   element of the list is always a "keeper", the modified list is
   always the same as the return value, and it's no longer strictly
   necessary for the caller to wrap this in a setq.)

   (defun delete-dups (list)
       "Destructively return LIST, with `equal' duplicates removed.
   LIST must be a proper list.  Of several `equal' occurrences of an
   element in LIST, the first one is kept."
     (let ((tail list))
       (while tail
	 (setcdr tail (delete (car tail) (cdr tail)))
	 (setq tail (cdr tail))))
     list)

Did we make a decision on this?  I know that Kim supports the change.
I do to, although _maybe_ one could change the docstring to:

  "Destructively remove `equal' duplicates from LIST.
Store the result in LIST and return it.  LIST must be a proper list.
Of several `equal' occurrences of an element in LIST, the first
one is kept."

to make clear that no setq is needed.

I believe that Karl is a project member and hence probably has write
access and signed papers, so he probably could install his new version
himself, with or without the above change in the docstring.

Sincerely,

Luc.

> Date: Sat, 14 Feb 2004 20:24:21 -0600 (CST)
> From: Luc Teirlinck <teirllm@...>
> 
> I believe that Karl is a project member and hence probably has write
> access and signed papers

Yes, he does.

In keeping with the earlier suggestion that it's better to keep
       the first of any duplicated elements rather than the last, I
       propose the following implementation, which satisfies that
       requirement and is also simpler.  (Note that since the first
       element of the list is always a "keeper", the modified list is
       always the same as the return value, and it's no longer strictly
       necessary for the caller to wrap this in a setq.)

       (defun delete-dups (list)
	   "Destructively return LIST, with `equal' duplicates removed.
       LIST must be a proper list.  Of several `equal' occurrences of an
       element in LIST, the first one is kept."
	 (let ((tail list))
	   (while tail
	     (setcdr tail (delete (car tail) (cdr tail)))
	     (setq tail (cdr tail))))
	 list)

I asked someone to install this.  You can install it if you want.

Luc Teirlinck <teirllm@...> wrote:

> /.../ can be achieved by slowly adding some CL-type functionality in
> ways that are philosophically compatible with Elisp, rather than
> adding tons of cl functions all at once.  I definitely believe that
> is the case and would wish that Martin would try that out rather
> than sticking with his current position.

I have nothing against using other equivalent functions when they
become available. However, the cl functions have a big bonus in my
perspective as a standalone package developer in that they are present
in all versions of Emacs and XEmacs that CC Mode supports. Therefore
it'll take a good while before I can completely replace them with
other variants.

>    I was referring to the maintenance problem, which I assume experienced
>    maintainers will understand.
>
> And by avoiding silliness like this.  /.../

Well, it's a matter of fact that my stance on this issue is a
maintenance problem when CC Mode is incorporated into Emacs, so Dave
Love is correct in labelling it as such and I'm not offended by that.

I really am sorry for causing this trouble. I think I've given
rational arguments for my position, and I'm prepared to change my mind
when shown sufficient rational arguments to the contrary. In that case
I'd also extend the explanation for the cl policy in the manual with
those arguments so that this isn't repeated.

> /.../ I am a user of cc-mode.  It is a very high quality program with
> remarkably little bugs for its complexity.  It is an important asset
> to the Free Software movement.  /.../

Thank you. :) I attribute the relatively small amount of bugs to the
extensive CC Mode test suite that Barry Warsaw started. By now it
contains a fair amount of tricky code snippets that have been
collected over more than seven years.

Dave Love <d.love@...> wrote:

> Martin Stjernholm <mast@...> writes:
/.../
>> That is the thing I definitely don't want to do. It's code
>> duplication
>
> As far as I remember, that didn't actually duplicate CL code.  It's
> the simple case that's normally wanted.

I meant duplicated functionality, not duplicated lines of code.

If your reason for doing it was improved performance, or ease of use,
by only implementing a special case then it's fine. But - as I said -
given the context of the discussion I assumed the reason was the
policy regarding cl and nothing else. Then it serves as a good example
of what I consider to be a disruptive effect of the policy.

>> and bad programming for a reasons so obvious I don't think I have to
>> elaborate on them.
>
> _I'm_ clearly not the world's best programmer, and I'm not responsible
> for the policy but I have actually maintained this stuff and things
> affected by it.  It's not obvious to me it deserves insulting remarks.

I apologize; my text was apparently open to misinterpretation since it
was certainly not intended to be insulting. What I meant to say was
that code, or rather functionality, duplication in itself is bad
programming. There can be reasons for that which outweighs the
inherent badness of doing it. In this case (still given that the
_only_ reason is to avoid the cl package), there must be sufficiently
strong reasons for not using cl to justify _all_ such code
duplication.

>> The fact that the cl policy forces code like that
>> makes it disruptive to an extent that is far out of proportion.
>
> No, this reaction is out of proportion.  If it's clear it's
> sufficiently useful to have something in the Emacs core, it will be
> put there.  (At least, that's how it was when I did it.)

I tried that route but failed. It was first after that failure I
reacted by ignoring the cl policy.

Granted, I tried to do it for a significant part of the functions at
once. In my view, they are so small and numerous so that it's overly
slow and cumbersome to discuss each one individually. Call me lazy,
but I simply don't muster to start a thread on a mailing list whenever
I find myself in a little corner of my current hack where I for
instance need a function that computes the union of two sets
containing strings, and then again for, say, a function that deletes
elements from a list using a predicate, et cetera, et cetera.

There ought to be a good coverage for all such reasonable cases to
begin with, and a tool package with that coverage ought to be designed
in one go with a coherent set of functions. As for myself, I'm unfit
for that job since I've arrived to the conclusion that cl already fits
the task better than anything else could. That is not based on any
aesthetic opinions of mine (I have none in this case), but on the
purely pragmatic reason that cl de-facto has filled the hole for a
long time and is already widely spread and well known, even though it
may only be used at compile time to be "kosher".

>> I can see no signs that cl-macroexpand would be an internal function.
>> How does it show?
>
> The prefix, and the fact that it's not documented.

I take it that the prefix bears special significance in this case,
since for other packages it does not imply that the symbol is
internal.

As for being undocumented, there is a blurb that shows up with C-h f.
That serves as documentation in my view.

Some time ago, Luc Teirlinck <teirllm@...> wrote:

> Martin nor me could reproduce the bug you described about cc-langs
> being loaded.  We now know that to you cc-langs is just an alias for
> cl, 

Claptrap.

Someone with a clue investigating, for instance, whether cc-mode
actually _used_ CL stuff at runtime would probably do something like
this in a fresh Emacs:

M-: (provide 'cl)
M-x set-variable debug-on-error t
C-x C-f /tmp/a.c

They'd then (perhaps) see a strange message in the echo area about an
error with no backtrace.  They might then guess to set
`debug-on-signal' too, which would provide a backtrace due to an
undefined CL function in a call tree which included something from
cc-langs.

That's just what I did.

> Martin said it was OK to make a change in cc-defs.el to prevent _cl_
> from being loaded.

Which clearly does not solve the problem, as above.

> There was no need to make any change to prevent cc-langs from being
> loaded at runtime, because that did not happen anyway.

eliz also said otherwise.  This is with current cc-mode source:

$ src/emacs --batch --eval "(progn (with-temp-buffer (c-mode)) (message \"%s\" (featurep 'cc-langs)))"
Loading cc-langs...
c-mode compiled with CC Mode 5.30.8 but loaded with 5.30.9 - evaluating language constants from source
t
$ 

> Your logic here beats me.

That's not my problem.

Could someone who knows what they're doing please look at this, and
note the issue even debugging it?  (Please mail me directly if
necessary; since this thread seems mainly to involve unhelpful
insults, I'm dropping it.)