From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Lisp files that load cl-lib in problematical ways Date: Mon, 23 Oct 2023 11:07:27 +0000 Message-ID: References: <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.org> <87r0lqoo5x.fsf@dataswamp.org> <83msweu76j.fsf@gnu.org> <87o7gungi1.fsf@dataswamp.org> <87pm17iilu.fsf@> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15834"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Bj=F6rn?= Bidar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 23 13:08:32 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qusnO-0003wp-PD for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Oct 2023 13:08:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qusmW-0004Hn-Ez; Mon, 23 Oct 2023 07:07:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qusmV-0004HT-7M for emacs-devel@gnu.org; Mon, 23 Oct 2023 07:07:35 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qusmT-0007Xd-0X for emacs-devel@gnu.org; Mon, 23 Oct 2023 07:07:34 -0400 Original-Received: (qmail 80986 invoked by uid 3782); 23 Oct 2023 13:07:29 +0200 Original-Received: from acm.muc.de (pd953a208.dip0.t-ipconnect.de [217.83.162.8]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 23 Oct 2023 13:07:28 +0200 Original-Received: (qmail 12068 invoked by uid 1000); 23 Oct 2023 11:07:27 -0000 Content-Disposition: inline In-Reply-To: <87pm17iilu.fsf@> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311701 Archived-At: 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).