Re: CC mode loads CL

[Martin Stjernholm]

Dave Love <address@hidden> wrote:

> Martin Stjernholm <address@hidden> 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.