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: Sun, 28 May 2023 22:59:05 -0400 Message-ID: References: <87bkivhqip.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39345"; 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 Mon May 29 05:00:00 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 1q3T71-000A3z-Me for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 29 May 2023 05:00:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q3T6S-0005M0-9Y; Sun, 28 May 2023 22:59:24 -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 1q3T6P-0005Ln-5K for help-gnu-emacs@gnu.org; Sun, 28 May 2023 22:59:21 -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 1q3T6N-00061L-BL for help-gnu-emacs@gnu.org; Sun, 28 May 2023 22:59:20 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1B8288065C; Sun, 28 May 2023 22:59:18 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5E62E80240; Sun, 28 May 2023 22:59:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1685329152; bh=Qd6I8GlXlepCnud/Y/nI4vb07L22Kt/P/uGfmdWOtZI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G1ajphsfDnv67Qr0qPzZnKcUuvhV72Ao0JyqqxIy6LqSxkRdNYWcRD1eE7kBDU9mA l4Gortwpl/l4fbZLexfh/ip/T/2bO42uavxt9zxBdCFWCsF/p3icv2dt3irr0sonSx B155FTmCEUDnKG8XzXdWHja4Pot6OyaTW7T+0bZa2nIGT9oLFIyUzOBBBX5U+ScjzG B4KmYfCbV7G5oxIozUOrZiTLGqkj+887m+AnKzjgTmT9ymld+ZQwEypz6IhfTZtP55 Rki8o8ZGeV0DByAPqrAPH810HjX+w5VLZOdQn21mMqPEJzXT0CR+YEaCkYBLWcF2SN RSo5ymhxObdSw== Original-Received: from pastel (unknown [167.88.20.246]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1A08B12025D; Sun, 28 May 2023 22:59:12 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Sun, 28 May 2023 18:42:26 -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:143780 Archived-At: >> I think `define-inline` is definitely not a good starting point for >> the above. > > If you mean literally the current implementation of define-inline, I'd > agree, except for the trick of defining both a compile-time (macro) > and a residual function. I see. I'm maybe too close to `define-inline`s design to see the larger picture (FWIW, the driving design is to take a compiler-macro and use it to generate the body of the function it is meant to optimize, because it puts the user of `define-inline` in charge of making it work, whereas the usual design is to start with the *function*'s body and automatically infer how to inline it, but that requires figuring out what should be inlined, avoiding name captures, etc..). >> OTOH you might be able to layer your `define-inlined-method` >> on top of the current `cl-generic.el`. AFAICT the main thing you need is >> some way to write a "call with enough =ABtype=BB annotations" such that = the >> dispatch can be performed at compile time. > I think that's the main point of designating parameters as "opaque", > so they aren't really specialized against, and only the non-opaque > parameters need to be wrapped in a form like (integer-ordering lt). > I'm still not certain that's enough to avoid needing a full-fledged > partial-evaluator embedded in the macroexpansion phase. Indeed, the difficulty I see is how to propagate info for cascading inlines (when inlining one call exposes info that (should) make another call inlinable). In most compilers, this is just "normal business" done by combining inlining with constant propagation, constant folding, etc.. (which you can call "partial evaluation"). But if you want to do it as part of macroexpansion, then you can't rely on the compiler's constant propagation, and constant folding. >> > Although I would change "inline-const-p" to test for function purity >> > (exclude stateful closures or otherwise impure functions). >> >> I think that would be a mistake. "const-p" doesn't mean that the return >> value is pure but that the expression itself always returns the same val= ue. > > I think you mean the argument value, not the return value? No, I mean that `inline-const-p` tells us something about the EXP it receiv= es, and this something is not that this EXP's return value is pure, but that this EXP always returns the same value. It's arguably a misnomer, what it really means is "do we already know what EXP will return?". This is evidenced by the fact that when we generate the function, the `inline-const-p` call is just replaced by t (because once we get to the function, EXP has already been evaluated so of course we know the value). > But that's exactly what I mean - a pure function is immutable, and > other functions change with state, so that in the extensional sense > they are not equal even if they are eq. > > For the purpose of partial evaluation, which I believe is the point of > inline-const-p, an expression `expr' is constant if > (equal (eval expr state0) (eval expr state1)) I agree. And indeed if `exp` is an expression which always returns `insert` or `buffer-substring`, then (equal (eval expr state0) (eval expr state1)) is true, even though `insert/buffer-substring` are definitely not pure functions. > Clearly exprs that are syntactic literals are constants by this > definition. Also, if `f' is a pure function, then (f C1 C2 .. Cn) for > constant expressions C1,..Cn is also a constant expression. Indeed, tho currently `inline-const-p` doesn't take advantage of that. Stefan