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 11:01:00 -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="17015"; 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 17:01:57 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 1q0O5l-000499-4e for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 20 May 2023 17:01:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q0O5F-0004qV-Sd; Sat, 20 May 2023 11:01:27 -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 1q0O57-0004q0-4G for help-gnu-emacs@gnu.org; Sat, 20 May 2023 11:01:18 -0400 Original-Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q0O55-0003ap-7Z for help-gnu-emacs@gnu.org; Sat, 20 May 2023 11:01:16 -0400 Original-Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1ae85b71141so14081605ad.0 for ; Sat, 20 May 2023 08:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684594873; x=1687186873; 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=q34FwKZ4/pXVzKx3N/ddnaIMTsYwrMuLMl/6XSZ6FR8=; b=gzNtkcTMp19E2nRSd4dbtXTVapkS+ALBonHJm1tdbrsPg3nUOGSlsNRrXmDCgwFjRq 3ZxML/7N5mLdSIFd8i4e8W97p22XpOGhaMA3ULEQ6JF6VNgNTI8/xUHtYZft8R+w8X4H NSUJAN2udzMQBr/WnYTpHcvYIsnmXuoA746ePc8Vr/vGWcQWHo4c8nX0VaQJe6rGyLig K1qjUSPw3AtCK8Wfqi4xvJnmMAZ0R8HY/7WU56V43jFQNIIzMptDkjS4FvTyn4nji21U 2b3Cf0NiIv6QiBNV/ILUa1H3cjeVEclEX1oIkyMkrMFuVeC99DvICTFOESoPn8KFSq6A tJHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684594873; x=1687186873; 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=q34FwKZ4/pXVzKx3N/ddnaIMTsYwrMuLMl/6XSZ6FR8=; b=YSvJmdF7ltu9dIPV4jiDc0FX2ERUEwEEyHri/1HesmRSb4w53hRaAOz92iCeGRBSow PUvuqfx+K925GPRhssZ/bU+35YdJ2myKKO2b30PBa2eDKGpk4FFaU6ZM+RNxPBATwguk jesB3d4TIZoJBzIz61U/n8uwQqTWiZlVQzQaNAkT0dHMFDQfMe3udaBncDuGtmgEy3oX qVnTG71S/bgL4XtC5Z2CR/2xy09+Vy1h5ULuxAlaBMbFQkJeY6e7knfDorud+8TVYdq0 shqHVatyNUhpgXGicCQs5ct6WC2GQxQnCQK4UPk5l997syAe5ScqPQ9wB3ptEo+YAouj l6hg== X-Gm-Message-State: AC+VfDwMhWFUou+OP+rGRYb3EBawtQl0vQ6Etc4UavTDiSrzcz/qOako kCp5j+e9vwh/qxsY82JeGKYcVtJzA+UZau35bqM= X-Google-Smtp-Source: ACHHUZ5diGqeJJIyRUvXdOONJPfKjT5Q4fNARS5Ff6N08W8O7jJ7wttzAi1fUc6QQ6dg50+k/NEwwcTO4wOyYXkjqu4= X-Received: by 2002:a17:903:26c6:b0:1aa:ebaa:51ce with SMTP id jg6-20020a17090326c600b001aaebaa51cemr6718759plb.14.1684594872691; Sat, 20 May 2023 08:01:12 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::632; envelope-from=owinebar@gmail.com; helo=mail-pl1-x632.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:143674 Archived-At: On Fri, May 19, 2023 at 9:07=E2=80=AFAM Stefan Monnier wrote: > > I'm trying to provide myself a tool for generic programming that > > dispatches at compile time. > > I still don't understand what you mean by that. > Do you mean that the programmers write > > (my-foo a b c) > > and during macroexpansion this is turned into > > (my-foo-for-thurbies a b c) > > when we somehow figure out that `a` is a "thurby"? For my purposes, an "interface" spec is just a list of method and slot signatures associated to some object, which will be realized by a set of bindings specified via special forms and bound to some name. Then a compile-time generic f is a factoring of a regular generic into a generic function of interface realizations that produces a concrete runtime function. I'm thinking to adopt the "place name" technique of naming the concrete function by the form that created it, ie. \(f\ arg1-iface-realizer\ arg2-iface-realizer\ ...\). Note the check is that the realizer provides all the required signatures (a superset), which is why I refer to it as a "constraint" on the interface implementation. Then the generic method could dispatch on simple wrappers created by the iface-realizers. If constructors are invoked at compile time when they appear in constant expressions and have constant arguments, then the generic multi-dispatch method specialized on those realizers can inline the call to the specialized method in the compiler macro, while a residual generic method could do the same dispatch at run-time. But the point is to separate the expression of the algorithm from the expression of the bindings that are used by the algorithm, without resorting to either dynamic dispatch tables or ad hoc macros per algorithm. > > I've been writing too much repetitive > > code, but I'm not a fan of ad hoc macros either. Basically, I'm > > trying to provide a C#-ish system for writing generic code > > parameterized by interface requirements. > > [ "generic code" and "interface requirements" are ... generic terms with > wildly different meanings in different communities, and I'm not familiar > enough with the C# world to guess what you mean by that. ] I only hacked on C#'s generics for about a month a decade ago, so it really is just my memory of the "flavor" of the generics being expressed by constraints on interfaces. > > >> > (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. > > > > That's the issue - if you use inline-letvals, then the code can't make > > use of constant values provided as operands. > > Are you sure? I think the real problem is that `inline-const-p` is not > a function but a macro, so you can pass it as a first-class function > E.g.: > > (define-inline my-plus (&rest args) > (inline-letevals args > (if (seq-every-p (lambda (x) (inline-const-p x)) args) > (apply #'+ (mapcar (lambda (x) (inline-const-val x)) args)) > (inline-quote (+ . ,args))))) > > seems to do (more or less) what your code illustrated. But then inline-const-val will (and inline-const-p) will get the symbol 'x as the operand, right? > > >> But also this will define the non-inlined version as something along t= he > >> lines of: > >> > >> (defun inline-+ (&rest args) > >> (if (seq-every-p ... args) > >> (apply '+ args) > >> (apply (symbol-function '+) args))) > >> > >> which is much too slow IMO. > > > > I agree. > > > > I posted a patch to emacs-devel for define-inline-pure-subr that > > adapts the technique of define-inline. > > I'm still not sure why you're not using a `compiler-macro` which seems > to be exactly what you're after. I'm very finicky I suppose. I want to get constant expression evaluation as automatically as possible, to enable the compile-time dispatch cleanly. Or are you saying that generic methods can be directly made into compiler macros? I was thinking I needed the original symbol redefined to avoid multiple macro expansions of the operands, as define-inline-pure-subr expands its operands before returning, so returning the inline-form is problematic. I also consider the property that inlining is uncooperative with advice to be a feature, particularly for pure functions. After all, the advice facility makes every function identified by a symbol impure. Lynn