From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: cl-eval-when -- A workaround for recursive require? Date: Fri, 29 Apr 2022 13:36:41 -0400 Message-ID: References: <86v8uuwwho.fsf@163.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1179"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Zhu Zihao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 29 19:37:26 2022 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 1nkUYY-00006t-9I for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Apr 2022 19:37:26 +0200 Original-Received: from localhost ([::1]:57752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkUYW-00017H-TB for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Apr 2022 13:37:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43836) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkUXw-0000RB-OF for emacs-devel@gnu.org; Fri, 29 Apr 2022 13:36:48 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12798) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkUXt-0001q3-OW for emacs-devel@gnu.org; Fri, 29 Apr 2022 13:36:47 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0AA0480677; Fri, 29 Apr 2022 13:36:44 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6957F805E4; Fri, 29 Apr 2022 13:36:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651253802; bh=50P7+nZy0/acxACuXtnNcteP0NpteLV8SSFOpl6x2ek=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RsNZaZ4nCYfTEUdvlsK5OFGge8lcoo+sFuK8BDYS1dzXrXDLqFp628l8+VHfbxdJt lQEYyQnJD99zUn9amqezdkG9sZk8RCjbETgw3k3Anujz7HjHT1ecxxxBpnwA7PMRaM 3h6XcEbOrOhO9fxV9/zvF3GsppJ2lVt5zdkNCeyLQIuk+43Wn1z/Q5Te6F9/hG8su8 9EN8odS04kjqKDJWLeOucPS3mptzo8OdrJUZ916JwOmZorsFvRL3hrZ7rneQrIstqV VdsCj5QxY/WoY9vN1fanO48TAg9fQ6Fsi5wn8CAL7a0eM6ADefjgFch8PzWXcM009j 4l8TgE4AQ1gcg== Original-Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 18DD31201B6; Fri, 29 Apr 2022 13:36:42 -0400 (EDT) In-Reply-To: <86v8uuwwho.fsf@163.com> (Zhu Zihao's message of "Wed, 27 Apr 2022 18:52:07 +0800, Wed, 27 Apr 2022 20:16:55 +0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" Xref: news.gmane.io gmane.emacs.devel:289015 Archived-At: Zhu Zihao [2022-04-27 18:52:07] wrote: > I investigated into the `cl-eval-when` a time long ago about this > `cl-eval-when` hack in the source of magit here. > https://github.com/magit/magit/blob/master/lisp/magit.el#L641 > > A breif summary: magit.el use a `cl-eval-when` block with load time and > eval time only evaluation to require its sub-components, while each > sub-component use `(require 'magit)` to use procedure in different > sub-components. This hack seems to be a hack to avoid recursive require. This kind of setup is quite common, but the resulting cyclic dependencies tend to be a nightmare. > The result of my investigation I remember is: "Don't use cl-eval-when, > it's not robust for many eval strategy combination. eval-when-compile or > eval-and-compile are more reasonable alternatives." I tend to agree. But when it comes to circular dependencies like that of `magit.el` the use of `cl-when-eval` is a minor detail. > The bytecomp.el file is a monolith and I don't know how to read and > understand it. Curiosity drives me to ask a question here: How does > `cl-eval-when` hack works for recurisve require? Is it a ugly hack? There's nothing special about `cl-eval-when` for cyclic dependencies. Some parts of `cl-eval-when` rely on ugly hacks, but I don't think it makes much difference here. The only sane way to solve these problems is to fix the circular dependencies, really. Often one of the best tools for that is to rely on autoloads instead of `require` for some functions, and the better way to do that is to use an "internal" autoloads file (i.e. one that's separate from the `-autoloads.el` loaded at startup and that's only loaded when the package is actually used). See lisp/**/*-loaddefs.el for examples of such "internal" autoloads files. We don't have great support for auto-generation of such files, tho, so sometimes it requires manual work to set it up (if you search for `;;;###` in `lisp/Makefile.in` you'll see examples of what I'm referring to). Stefan