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: Wed, 22 Sep 2021 09:54:12 +0000 Message-ID: <8735pxq6kb.fsf@posteo.net> References: <877dfavmzw.fsf@posteo.net> <87pmt1wor5.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34569"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 22 11:55:06 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 1mSyy2-0008ng-6E for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Sep 2021 11:55:06 +0200 Original-Received: from localhost ([::1]:55884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSyy1-00061O-2X for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Sep 2021 05:55:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSyxM-0005Al-20 for emacs-devel@gnu.org; Wed, 22 Sep 2021 05:54:24 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:59287) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSyxI-0005BX-19 for emacs-devel@gnu.org; Wed, 22 Sep 2021 05:54:23 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 831FD240110 for ; Wed, 22 Sep 2021 11:54:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1632304457; bh=K9+eCGzwtuCo3+z+XKeHbiFWhw2FuaW4u2zN/JBNNzM=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Bv/oReURw5dpDlSdE79A4bGV+YwWT/NO3K8n/4dFvMO1Aw1pZxcZV53wniD6gqzy3 yfce93STnHeH5Gz409ULdfyyalzYzZoVy0hGDzUGrVJ7ch1//loVRI/pyJOZNFMEXi lnig2hY3qnKEqPCeazLZ6oyzbLTFXqo6MMb/tndtoHtzlEL/pFCrGATlsPKKB94K0w Mql6oF1KeahdvM/T8l+qOdwLn5qaDZxk91u9uFawFlOyZ2/GuwVsy+e/ucF6anRNxi HzReb3dFZhJ9A2ozcjNeap4bw1nm0kYYZtfmBgMa6Xs3VU3TCr5/bH2J2BoGqex3Gz fhbSVqJFHjIew== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4HDttJ14TXz9rxX; Wed, 22 Sep 2021 11:54:16 +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: <87pmt1wor5.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 22 Sep 2021 00:24:46 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) 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=unavailable 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:275308 Archived-At: Lars Ingebrigtsen writes: > Richard Stallman writes: > >> > The idea is to allow developers who don't want to break backwards >> > compatibility to use newer functionality that wasn't provided in older >> > versions of Emacs. This version tries to implement as much as possible >> > from Emacs 24.2 onwards. >> >> Would you please state concretely what this package would do? Functionality-wise: The package uses custom macros to define "compatibility functions". A compatibility function implements at least a subset of the behaviour the "real function" would provide, if it were defined in whatever release of Emacs. The macros it provides are: - compat-defun Defines a compatibility function that is only aliased to the "real" symbol, if this is unbound and the specified version is greater than the current version. Example: (compat-defun always (&rest _arguments) "Do nothing and return t. This function accepts any number of ARGUMENTS, but ignores them. Also see `ignore'." :version "28.1" t) On Emacs 28.1 an newer, this just expands to `nil', because the plist after the documentation sting specifies that this function was defined in Emacs 28.1. Other attributes can be given such as part of what library this function was defined, so that it is wrapped in an eval-after-load body, preventing the developer from using the function, without loading the right library beforehand. Otherwise it defines (defun compat--always (&rest _) "[Compatibility function for `always', defined in Emacs 28.1] Do nothing and return t. This function accepts any number of ARGUMENTS, but ignores them. Also see `ignore'." t) followed by (unless (fboundp 'always) (defalias 'always #'compat-always)) - compat-macro Analogous to compat-defun, just for macros. - compat-advise Defines an advice function that is then applied to wrap (ie. :around) the actual function. Example: (compat-advise sort (seq predicate) "Handle SEQ of type vector." :version "25.1" (cond ((listp seq) (funcall oldfun seq predicate)) ((vectorp seq) (let ((cseq (sort (append seq nil) predicate))) (dotimes (i (length cseq)) (setf (aref seq i) (nth i cseq))) (apply #'vector cseq))) ((signal 'wrong-type-argument 'list-or-vector-p)))) Again, it defines a compat--sort function with the same body as compat-advise, and an additional argument "oldfun". - compat-defvar Defines a variable, constant, buffer-local or permanent-local variable, again using a version attribute and boundp to check if it should do so. I plan to add at least compat-defface, for defining faces that older versions of Emacs didn't provide. > The library defines versions of newer functions if Emacs doesn't already > have them. For instance, Emacs 28 has a new function > 'buffer-local-boundp'. Philip's library would provide a definition of > functions like that for use in ELPA code that's written for newer Emacs > versions, so that they can be used in older Emacs versions without > introducing compatibility shims like `foo-package-buffer-local-boundp'. > > This also allows us to put (more) core packages into GNU ELPA without > any code changes. I am not sure if no-code-changes are always possible, but that would be the best-case scenario. >> > 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 have a plan to put those names into optional namespaces (using >> symbol renaming) so that the entry points of those packages will >> be visible only from packages that require specific libraries. > > Philip shouldn't have mentioned s and dash and the rest -- his proposal > has absolutely nothing to do with those, but it seems like many people > have lashed onto that part, somehow. The reason I mentioned these libraries at all, is that for more than a few package developers, I have noticed that they use these libraries for the sake of convenience *and* backwards compatibility. As these libraries are updated externally, they provide more easily usable functionality that wasn't given in say Emacs 24.x. If they are interested in convince and less repetitive programming, as I am sure many are, they would have to choose between raising the minimal version required to use their package or to add these external libraries. My point in mentioning these was not to give a direct comparison, but just to say that if compat.el didn't use transparent compatibility, it would just become another utility function library -- just instead of using a Clojure style of programming, it would stick to the more traditional Elisp conventions. -- Philip Kaludercic