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: Do we need C's extern in Emacs Lisp? Date: Thu, 31 Mar 2022 17:16:24 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33685"; 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: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 31 23:18:28 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 1na2BY-0008X9-Af for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Mar 2022 23:18:28 +0200 Original-Received: from localhost ([::1]:48832 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1na2BX-0002eO-1G for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Mar 2022 17:18:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55204) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1na29i-0008RK-PG for emacs-devel@gnu.org; Thu, 31 Mar 2022 17:16:34 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56171) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1na29g-0005cm-4h for emacs-devel@gnu.org; Thu, 31 Mar 2022 17:16:33 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E2662100163; Thu, 31 Mar 2022 17:16:28 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 64DE61002B9; Thu, 31 Mar 2022 17:16:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1648761386; bh=SpnEUsqagI+X1/v90rOrhbwpfYSlM+Mqtu3qCDMsx0k=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Vzo+4UbxUDu7bepbayflmR4ks6LkL01WIJqT9B1uLU6GUjVEFIaMmxs3Zb+Y5sg9e UpoT3HJCXM8/7kjhOwwRlLkTPwmgsvJS0weqpDdzNarC1hfzZAJxb7nMMnZ3kEnQMS Ss3HpJO45/V8slr+lbcnaayQQyqap3w/cdTvbwj+gwzygB7rCP6Km9xKWv++t5Y9b/ 6G7X4TNG1WKNQGm+DMlmcCRR9OxmKTeqAZJ4R1ajwa9eRmnuFHYu4Dcow+22U7XoRQ VpgWq75LqIIgzHS/3MYdiZ2y+E3cjhY0wbItEm0VAosnyzZu6FE2O02O5DxyKXRrtZ N+yvKeL3Z1Tpw== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 018AD12020D; Thu, 31 Mar 2022 17:16:25 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Thu, 31 Mar 2022 20:59:36 +0000") 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:287646 Archived-At: > I was wrong about the "subsequent use ... generate an unknown variable > warning.". Sorry. The problem happened during a more unusual > compilation situation best explained by the following comment from > cc-fonts.el: > > ;; Need to declare these local symbols during compilation since > ;; they're referenced from lambdas in `byte-compile' calls that are > ;; executed at compile time. They don't need to have the proper > ;; definitions, though, since the generated functions aren't called > ;; during compilation. > > The "need to declare" means "need to give the value/function cell of the > symbol a binding", because the byte compiler seems to use boundp and > fboundp to check whether to emit "not known" warnings. Explicit calls to `byte-compile` are rather unusual, indeed, and since declarations like (defvar FOO) are supposed to affect the code only in the current lexical scope they can't be applied to this use case since calls to `byte-compile` are dynamic and thus not easily associated with a particular lexical scope. Arguably we should be able to provide some kind of "environment" argument to `byte-compile`, but for your use case, maybe the better option is to wrap the code that you pass to `byte-compile` along the lines of (defun my-byte-compile (form vars funs) (eval (byte-compile `(progn ,@(mapcar (lambda (v) `(defvar ,v)) vars) ,@(mapcar (lambda (f) `(declare-function ,f nil)) funs) ,form)))) > "This variable/function is defined somewhere" is a natural thing to want > to say. The (defvar foo) and (declare-function foo nil) don't say this, > exactly. Those declarations don't just say "defined somewhere" but something closer to "will be defined somehow by the time we get here" (tho admittedly, it's a lot more murky). This is usually more useful since it justifies removal of the warning by promising that the corresponding runtime error won't happen. It's less clear what we can do with just "this variable/function is defined somewhere" since it doesn't do us much good if it's defined in a file that never gets loaded. Stefan