From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.help Subject: Re: inline function expansion Date: Sat, 20 May 2023 10:18:43 -0400 Message-ID: References: <87bkivhqip.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19743"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , help-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 20 16:19:20 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 1q0NQV-0004uB-CH for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 20 May 2023 16:19:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q0NQD-0007pJ-FH; Sat, 20 May 2023 10:19:01 -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 1q0NQA-0007ou-AE for help-gnu-emacs@gnu.org; Sat, 20 May 2023 10:18:58 -0400 Original-Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q0NQ8-00042U-IZ for help-gnu-emacs@gnu.org; Sat, 20 May 2023 10:18:58 -0400 Original-Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-253724f6765so2107540a91.3 for ; Sat, 20 May 2023 07:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684592335; x=1687184335; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vhBgs75aleRbK5PYGfS0/0U48fnM2t2qu8jOTwn2SDg=; b=l3ak2AQIFyTlIl5n5+bSFJLWDQf66qXlRvR4qyr17VVo0EOkbAC8owQen0uQaZ+Sjt 2rqgRyYbpeb72Jff6eWAwj0soCy8+VhVqo/ji9mJXA8fFcku1S+2vEthUpJ9ofLqKojZ i7DynuyoVHUaI76kDVTDEJ4VtZM8X2hCYZf0hHuZ3T44QRKKmP9IO0dmhyigZHhfN2R5 GTXBlKp7AX2BcyXi87qBLKMV39WSZtwo5Ly3cc8uRZLku13qhipOyeducXt+C1SaaoyF sRqJkvnk0TKmv3PnvHgxQAsY3AVDEgdYv0sPrCFb/4kI9UYDrPlxBIwawvtQLS0Nm17I H5WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684592335; x=1687184335; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vhBgs75aleRbK5PYGfS0/0U48fnM2t2qu8jOTwn2SDg=; b=WxeTA8CPROKOHpGEUE69UbZJh29zzeIQRm2HE+5JTbbgmF2ucwu5Ica3mx7o5qUkIG 9BqQ9JC6fZq2YwnSnc6gjOVfNjdVq288QyT5e6D73B8WzL0Huff8UkWcIevbhdNL6asV e8IZeAgws6duWLO9LKmYwC8Q8cuZ+9opY/cp1k1Xj8VW/oLDTS8AnSPlP39s9fD70pFH lxwSbq/evH9R2z29lRgprmOa/UJXBjJq4xy5WZAqyZ9WwnKWL+3anBjhfccgm/h7KV9g hdxeSbUBO5YY5/23momRHg8ENOaSdkE32CaYOkcX1ieFH9HhPnZx6UtruEg7T43nlE34 V7Tw== X-Gm-Message-State: AC+VfDzW+8zpiDcAR8Sfmiwz8V0drddgd12CoyWLUEw+dhcqKdJ5eB2m 6paGfzWqgEMgIMdxS6aiIr+DZt1pKes9+qzxlys= X-Google-Smtp-Source: ACHHUZ6Ps83ZFkF8JWQ2lWsuE2LlJT3Z9JRMrjOzlV7YLL0F7zhv3FSf1vMhFtzWW3LWttDUMVJO2WLARx9ViRW18MI= X-Received: by 2002:a17:90a:2905:b0:255:4f13:fee0 with SMTP id g5-20020a17090a290500b002554f13fee0mr41998pjd.13.1684592334731; Sat, 20 May 2023 07:18:54 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1029.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:143673 Archived-At: On Fri, May 19, 2023 at 9:31=E2=80=AFAM Stefan Monnier wrote: > > After some more investigation, the only other code I've seen that uses > > define-inline to do more than defsubst would (as I understand it) is > > in gnus-sum.el: > > (define-inline gnus-summary-article-header (&optional number) > > "Return the header of article NUMBER." > > (inline-quote > > (gnus-data-header (gnus-data-find > > ,(or number > > (inline-quote (gnus-summary-article-number))= ))))) > > And I believe that occurence of "number" should be > > "(inline-constant-val number)". > > 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. > > > One example where there could be a use of define-inline's additional > > functionality is in: > > (define-inline cconv--var-classification (binder form) > > (inline-quote > > (cdr (assoc (cons ,binder ,form) cconv-var-classification)))) > > > > That could be changed to > > (define-inline cconv--var-classification (binder form) > > (inline-quote > > (cdr (assoc ,(inline-quote ,(cons (inline-const-val binder) > > (inline-const-val form))_ cconv-var-classification)))) > > I think you can simplify that to: > > (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? > > 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? > To support this kind of optimization we'd need to add specific support > for it to `define-inline`. > > > Automating the first one involves identifying the maximal constant > > expression containing each potentially constant parameter, which is > > hard in general. But if we restrict the language handled by the > > inliner, it might be doable. For example, if we could assume no > > macros implicitly bind any identifiers already in use, and parameters > > marked with &const as a guarantee that the result of the function > > does not vary based on state associated with them, maybe that would be > > enough to determine non-trivial subexpressions pure subexpressions > > above rather than forcing the user to identify them explicitly by > > unquoting. > > The driving principle behind `define-inline` is to not do any analysis > and leave that responsability in the hands of the users of > `define-inline` :-) > > So we could/should add some special annotation like (inline-precompute > ) which treats as an expression that builds a value and > precomputes it if all the `,` that appear in it are > `inline-const-p`. > > > For the second, I'm thinking that what the programmer wants to > > express is that if the "type" parameter is constant, then reducing all > > forms with pure operators with respect to type is a "pure" macro in > > the sense that it will always produce the same expression, and that > > expression has no occurrences of "type". > > Note that in the case of `cl-typep` the expansion may fail to fully > eliminate the "type" parameter, IIRC (i.e. it manages to inline/unroll > part of the recursion but not all of it because some part of the type is > not statically known or too complex). I don't know what "too complex" would entail, but if it's not statically known then the type arg isn't really a constant so it's not really a failure. > > > Then assoc is pure because when all three arguments are constant > > (i.e. the test function is pure), then the value is constant. > > 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. Also, I don't get why logand isn't considered a pure function - 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)? I could see it making sense historically, but is it still a useful property of byte-code?