From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Proposal: Forwards-Compatibility Library for Emacs Date: Tue, 21 Sep 2021 12:58:36 +0000 Message-ID: <875yuut79f.fsf@posteo.net> References: <877dfavmzw.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="22505"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 14:59:26 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mSfMr-0005eh-BE for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 14:59:25 +0200 Original-Received: from localhost ([::1]:46608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSfMo-0005c6-RF for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 08:59:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSfMD-0004rc-WF for emacs-devel@gnu.org; Tue, 21 Sep 2021 08:58:46 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:36719) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSfM9-0001h2-Om for emacs-devel@gnu.org; Tue, 21 Sep 2021 08:58:45 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id A930F240101 for ; Tue, 21 Sep 2021 14:58:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1632229118; bh=okws5ilePtt7jhxxyCdtLQWoT+Lmj3JkO5/kBCwGOPk=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=ZLFTwpIIwlWadEX/g/Gpo14WN8/WjWNhMljTY1waz5C+ZMXMhrVu+QxIpECMQiyIW 7KhNx+8FYn8EpN1wmHqVezv9RqhvL17Kg8RnKlpZaqhyTmqP33mbKIcN/RoMP5sqjP ljtDhiEb57bUtKHdlb8uPT647SSIO1OyMGV95ewYMYTOenQbqKDwSpxT/BvgTmeTTC pwFuTlhibaSXPMEYGTowzhO4bEnGXL1E9elhE9xQ8B54HxGLYviWFF6g5R0xhcAhq3 0hPX/aDFDgszr9snQIhqcdHnWyMeIy96YTreRgNwqlGGM82gbrttnfuV1EGoKar5A+ uzCelnv/UUDSg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4HDM1T3tv9z9rxp; Tue, 21 Sep 2021 14:58:37 +0200 (CEST) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: (Stefan Monnier's message of "Tue, 21 Sep 2021 08:31:39 -0400") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275223 Archived-At: Stefan Monnier writes: >> By its very nature it is an intrusive package, as it defines functions, >> macros and advice outside of the "namespace", but I don't see any way >> around that if transparent compatibility is to be provided (anything >> else would just replicate dash, s, f, ...). > > I think this uncleanliness is a bit risky. Better put the definitions > in their own namespace. Just to be on the same page, what exactly is the risk? I understand the issue on a gut-level, it goes against convention and recommendations, but the idea is that this package would do that, so that others don't have to. Other than that, all the functions and macros are defined first using a "compat--" prefix, then perhaps are aliased to a symbol without a prefix. > I don't think "transparent compatibility" is > worth the trouble here, and I don't think `s`, `f`, ... solve the > same problem. Of course not, s, f, and the rest of the dash-adjacent ecosystem have different intentions, it is only as a side effect that they provide more functionality than older versions of Emacs do. Most of the examples I provide in the file I attached above are simple or slower reimplementations that make programming more convenient, but where "transparent compatibility" becomes interesting is when providing noop compatibility that allows package developers to make use of newer features that are not backwards compatible, such as the additional interactive argument. The infrastructure doesn't exist to handle this information, but package developers will hold back from using these new features because they don't want to abandon all users that aren't on 28.1. I don't see how examples like these could be handled without transparent compatibility. > Stefan -- Philip Kaludercic