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: Thu, 18 May 2023 14:29:18 -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="31053"; 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 Thu May 18 20:29:59 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 1pziNz-0007q6-2Q for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 18 May 2023 20:29:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pziNW-0005Qz-Ip; Thu, 18 May 2023 14:29: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 1pziNT-0005Pv-CS for help-gnu-emacs@gnu.org; Thu, 18 May 2023 14:29: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 1pziNO-0003bv-MK for help-gnu-emacs@gnu.org; Thu, 18 May 2023 14:29:24 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C153C8022B; Thu, 18 May 2023 14:29:20 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6255E80ADE; Thu, 18 May 2023 14:29:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1684434559; bh=5w3edBwUXmFi2tp2R+CW8594GktDe3yK0BCgNkmwdUg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oDADfG9RXtqIvaVTHf3nITFKskvSDGlPVxnUO8Yd2j63+Cz5Fn9+Ixt3PRR41WqJ6 n56GcXUiuM7hUo26wl0TNNfVYjjDYAes56qyKcLn/Li7ot3kqrtI1WKPTIq7gXPT1q WJaFguhdjUdSRwjUCmiy3uFVX8QLo1EvH3v7KmnDVs94m2ynv0Y/TbQawHIGVVLsfG SMHuMCn32BVQsOBJyF6L0gCuwgz38ppw0lHC1uB0cNqjj8KmJBefQbHN1+7ImozwAm 6zpOaBkynZGJ3MIzNoMBi/YdLKmw23IH7ZhhT/rkfvM3c2ACvTC1NKdZAbtp7uI2Yj AAs8QCGuF679w== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 522E7120321; Thu, 18 May 2023 14:29:19 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Thu, 11 May 2023 03:11:14 -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:143646 Archived-At: [ Sorry, this also feel through. ] >> Isn't the idea of inlining that the behaviour/effect of invoking a >> function shouldn't change, just that the resulting code might be more >> efficient? Indeed, but `define-inline` is a tool that lets you define the inliner at the same time as the non-inlined definition, and it's up to the user of `define-inline` to make sure the inliner gives the right result (tho `define-inline` tries to make it easier to DTRT). > I'd like to define inline- variants of pure subrs, e.g. arithmetic > operators, type-predicates, that evaluate during macroexpansion rather > than involving the compiler's optimization phase. `define-inline` is definitely not meant for that use-case, since it's designed to have a single definition that does both: - define the inliner. - define the non-inlined version of the code. In your case, the non-inlined version is written elsewhere :-( Instead, you want to use a "compiler macro". Moving optimizations to the macroexpansion phase can have many benefits, indeed (e.g. it lets those optimization affect the subsequent closure conversion), but also downsides (you may get more warnings about chunks of code over which you have no/little control, like "unused variable" warnings in places where the vars is "used" by code that's optimized away). > I think it will be easier to ensure compile-time generic methods > (e.g. a macro that simply calls a generic method) will (or at least > can) dispatch during macro-expansion, without involving the > byte-compiler's optimization phase. I don't understand this, sorry. > (define-inline inline-+ (&rest args) > (if (seq-every-p #'inline-const-p args) > (apply (eval-when-compile (symbol-function '+)) args) > (inline-quote (,(eval-when-compile (symbol-function '+)) . ,args)))) IIRC you definitely need an `inline-letvals` somewhere here. But also this will define the non-inlined version as something along the lines of: (defun inline-+ (&rest args) (if (seq-every-p ... args) (apply '+ args) (apply (symbol-function '+) args))) which is much too slow IMO. Stefan