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 13:54:03 +0000 Message-ID: <87bl4mrq4k.fsf@posteo.net> References: <877dfavmzw.fsf@posteo.net> <875yuut79f.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="40622"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 15:56:53 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 1mSgGT-000AOX-4X for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 15:56:53 +0200 Original-Received: from localhost ([::1]:59214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSgGS-00074S-1H for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 09:56:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSgDt-0004eE-GU for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:54:13 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:43319) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSgDq-0007tj-Qr for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:54:13 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 1294924010C for ; Tue, 21 Sep 2021 15:54:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1632232447; bh=IyIBq85aGE6pXqQGnau4bs6RACJvEuB0uZwEeEKbzK4=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=macOJUR3FgOt6Rbmpcb5hKFMpsfrMC+WJCTIdrj+dpA47gcsIVw5K/M+i6ARLEixA vk6YKhJ5arb1bhfK/3739Xx4WJsxvIDtXf/Zg/EyNkXsU5VRjvpNrTC2OO3GRkP4IA Gtza+TvkzjW70o4nd839V5PqWCXqScUBIenUqktIY5Mk3WMKQDOLL4Lgzfu+MLYJWY vX7JwPq6owgHQlF51r441zq7+RDH+g3U+nSV6xlgZ5gjH5ah6tkQvRzQZF+PiGMTnI u321AlqZTyMSi4Vxl7jInHbL/eh7//MA5pj6K2jQP9EnYZCIcBCrIhsC/l0bKcMCNs zRkL+VducT4HA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4HDNFR4hC5z9rxj; Tue, 21 Sep 2021 15:54:03 +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: (Arthur Miller's message of "Tue, 21 Sep 2021 15:37:07 +0200") 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:275239 Archived-At: Arthur Miller writes: > Philip Kaludercic writes: > >> 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. > > It is not on a "gut-level" :). I was thinking about same, and wrote you a longer > answer I just sent. There were no replys when I started, I see now several > people replied. > > There can be two functions defineing slightly different behaviour in different > version, there can also be 3rd party packages expecting certain behaviour, and > there is no need to advise too much, say windowing code if application need to > just check is directory-empty-p. Yes, I think cases where different versions switch back and forth are hard to make compatible, so they should be left out of any attempt like this. >> 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. > > They define different API from Emacs, more used by people comming from different > Lisp(s), clojure if I am correct? >From what I know they are inspired by Clojure and try to provide better compatibility with the various macros that dash provides (such as threading), but I am not sure if they are direct translations from Clojure's standard library. >> 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. > > When it comes to providing newly intoduced functionality, there shouldn't be a > problem, it should always be possible to just add a function, like > dired-empty-p: > > > (when (version< emacs-version "28") > (defun directory-empty-p (file-name) > "Check if a directory contains any other files then dot-files" > (when (file-directory-p file-name) > (null (directory-files file-name nil > directory-files-no-dot-files-regexp t))))) > > You don't even need to advise directory-files for that. That wouldn't even be advised. My definition (compat-defun directory-empty-p (dir) "Return t if DIR names an existing directory containing no other files. Return nil if DIR does not name a directory, or if there was trouble determining whether DIR is a directory or empty. Symbolic links to directories count as directories. See `file-symlink-p' to distinguish symlinks." :version "28.1" (and (file-directory-p dir) (null (directory-files dir nil directory-files-no-dot-files-regexp t)))) is expanded to (progn (declare-function compat--directory-empty-p "compat" '(dir)) (let nil (defun compat--directory-empty-p (dir) "[Compatibility function for `directory-empty-p', defined in Emacs 28.1]\n\nReturn t if DIR names an existing directory containing no other files.\nReturn nil if DIR does not name a directory, or if there was\ntrouble determining whether DIR is a directory or empty.\n\nSymbolic links to directories count as directories.\nSee `file-symlink-p' to distinguish symlinks." nil (and (file-directory-p dir) (null (directory-files dir nil directory-files-no-dot-files-regexp t)))) (compat-ignore (defalias 'directory-empty-p #'compat--directory-empty-p)))) which is more or less the same as what you do (setting aside the fact that on my system, the installation via defalias is ignored). > But for already existing functions that might lead to problems. I think so at > least. In the answer I sent you, I was thinking of buffer-local function > variables instead of advices which are global. -- Philip Kaludercic