Re: CC mode loads CL

[Martin Stjernholm]

Dave Love <address@hidden> 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  <address@hidden>
>
>       * 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.