emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lisp files that load cl-lib in problematical ways


From: Alan Mackenzie
Subject: Re: Lisp files that load cl-lib in problematical ways
Date: Mon, 23 Oct 2023 11:07:27 +0000

Hello, Björn.

On Sun, Oct 22, 2023 at 03:52:29 +0300, Björn Bidar wrote:

[ .... ]

> >From my point of view in some way it does sound like that some are
> against it [the use of cl-lib] for ideological reasons rather than
> technical.  E.g. those that makes code unreadable or lets rewrite
> something to drop the dependency to not load it.

You seem to be saying that avoiding making code unreadable (i.e.
difficult to maintain) is an "ideological" thing.  Here "ideological"
means "can be dismissed without consideration", I think.

> It does sound like a generational conflict, newer developers write code
> sometimes different than older ones.

I think it's more likely to be a "conflict" between those who have to
maintain other people's code and those who merely write it.  But seeing
as how I'm the only member of the first group to express a view on this,
it's difficult to be sure.

> Why not use cl-lib when it makes it easier to achieve what I want easier
> and easier to understand than "vanilla" elisp.

That's a big "when" you use.  If the use of cl-lib actually did make
things "easier to understand", I would agree with you.  But it doesn't.
I'm speaking from bitter experience here, like trying to track down a bug
at one o'clock in the morning, and encountering some obscure cl-lib
function or macro.

A great number of them are obscure.  They have inadequate doc-strings, if
any at all.  That is to say, doc-strings which don't say what the thing
does, and don't say what the parameters mean or give their form.

As an example, take the last macro in cl-macs.el, `cl-deftype'.  Its doc
string is just

    "Define NAME as a new data type.
    The type name can then be used in `cl-typecase', `cl-check-type', etc."

..  At 01:00, I need to start asking what is NAME?  Is it a symbol?  Is it
a string?  Is it, perhaps, some type of list structure?  What does it
mean to "define" it?  And what exactly is meant by a "data type"?  And
there are the other two parameters ARGLIST and BODY which are not
mentioned at all, and would appear to have nothing to do with defining
data types.  In practice, this means having to study the source code of
several functions/macros in detail, something which would be not be
needed had it not been used in the first place.  This is unrewarding,
tedious, and time consuming.

This poor standard of doc strings is typical throughout cl-lib, even if
not universal.

> But as other said, this wasn't the point of the thread even when some
> messages did sound very ideological.

Some, perhaps, but not all.

> > On the other hand if it _is_ useful - and the number of people
> > using it and the number of files where it is used, and the
> > number of occurrences indicate that it is - there is no reason
> > to disencourage people from using it, anywhere.

I have outlined a reason above.  Fifty years ago, you could have been
saying the same about the goto statement.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]