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.help Subject: Re: inline function expansion Date: Sat, 20 May 2023 11:32:17 -0400 Message-ID: References: <87bkivhqip.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3959"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Philip Kaludercic , help-gnu-emacs@gnu.org To: Lynn Winebarger Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 20 17:33:04 2023 Return-path: Envelope-to: geh-help-gnu-emacs@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 1q0OZq-0000jz-Dc for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 20 May 2023 17:33:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q0OZK-0001y3-1n; Sat, 20 May 2023 11:32:30 -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 1q0OZI-0001xu-SZ for help-gnu-emacs@gnu.org; Sat, 20 May 2023 11:32:28 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q0OZG-000167-Vf for help-gnu-emacs@gnu.org; Sat, 20 May 2023 11:32:28 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E6BA4440771; Sat, 20 May 2023 11:32:24 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3DC9244004C; Sat, 20 May 2023 11:32:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1684596739; bh=SJlqzO0OY81p78R9ULK6GsCrEselmlQ+aFlBDSYCZFY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=T+rVnZyhGiBl45cmRBsLdnsLMuuzvTw98Lt6BeZ4AQfJVocjHgu+IKmNyu7LXtVV/ /nprE1oKouk/czhmLvHQMDirwCS/iJf21rJEfqVoa4Lizvd6q0Ke/DOpfF95hjx8m6 MRT7JgY0oLM+ETIs1T3v1v0GWqcvvX4/YsotlkG1jaVCR6vf1Q5p1i2Q+DPgFoSxtu zlmADT2IYqMM8kUY44Usc7SZzA2AxCDQ8FbqeTU9GvIB2owKt7Ip+HiMNesQ6YM/by lG8Xk45yhiJ2V9YzUR09ixDlvqn4z8GCo8RygyEAjb0cno/DfNb9s3TC4h6w3IEEQK w7IhD+dcvTcsw== Original-Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0E53D1203C4; Sat, 20 May 2023 11:32:19 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Sat, 20 May 2023 10:18:43 -0400") 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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:143675 Archived-At: >> You're right, tho in practice number is either nil or non-constant, so >> it doesn't make much difference. > I'm just pointing out it is difficult to tell how to use the > facilities for compile-time evaluation provided by define-inline. Oh, that, yes the `define-inline` facility is hard to use, no doubt. I'm not happy with it. This is also reflected in the lack of doc because it's difficult to document it much better than "look at the code, try it out, and fiddle until it works" :-( >> (define-inline cconv--var-classification (binder form) >> (inline-quote >> (cdr (assoc ,(cons (inline-const-val binder) >> (inline-const-val form)) >> cconv-var-classification)))) > > Don't you need something to add a quote to the cons cell when "binder" > or "form" are not constant? Oh, you're right. >> but here as well, this optimization would never apply because those args >> are never literal constants. Worse: the failure of `inline-const-val` >> would cause the whole inlining to fail :-( > Could inline--do-quote catch the throw? It could, but it doesn't (and it would be an incompatible change). >> IIRC the reason it's not "pure" (for some definition of "pure") is >> because it can signal an error. > > The byte-opt.el code from v28.2.50 says it's because the third > argument may be an impure function: > ;; `assoc' and `assoc-default' are excluded since they are > ;; impure if the test function is (consider `string-match'). > I'm not sure why the possibility of signaling an error alone would be > disqualifying. For example, (+ 5 's) signals an error. Oh, you're right, sorry. So the problem is if the test function is constant but not pure. > Also, I don't get why logand isn't considered a pure function What makes you think it's not? ELISP> (symbol-plist 'logand) (gv-expander #f(compiled-function (do place &rest masks) #) side-effect-free t pure t) ELISP> > How important is it to be able to run byte-code generated by > a 32-bit emacs in a 64-bit emacs (or vice-versa)? The Emacs tarball comes with all the `.elc` files, so it's important that `.elc` files be portable across architectures. Stefan