From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Proposal: Forwards-Compatibility Library for Emacs Date: Tue, 21 Sep 2021 16:40:55 +0100 Message-ID: References: <877dfavmzw.fsf@posteo.net> <87czp2c6qd.fsf@gnus.org> 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="24474"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , Stefan Monnier , emacs-devel To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 17:42:03 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 1mShuE-00064s-Pe for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 17:42:02 +0200 Original-Received: from localhost ([::1]:53800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mShuC-0006j7-ID for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 11:42:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mShtO-0005xg-G4 for emacs-devel@gnu.org; Tue, 21 Sep 2021 11:41:10 -0400 Original-Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]:36586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mShtM-0000dF-RD for emacs-devel@gnu.org; Tue, 21 Sep 2021 11:41:10 -0400 Original-Received: by mail-pj1-x102b.google.com with SMTP id z14-20020a17090a8b8e00b0019cc29ceef1so2285038pjn.1 for ; Tue, 21 Sep 2021 08:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XtI4kI7xmiFZKdJhl2L14WuOPVxHEdPjwBT9muXmIkA=; b=Wy+h6xnkfpeDo4YhsXb8HPrKELD58GEN6hn13iaLzuHTQwLkhLM8f2pmhLkGTApOjR YA/89LohtErhEUBu4p1aezMcLUurG3T6svyRZwWckquIxoucEPlrX9yEvsiy65UmzgXm cJoiegzhknv0Os76zA+CxIKitF5j4JolspL0SA5fXiJKTxDhoj4CL1wMRNv5mQHyZqGS 7qonH3odG7HPlS1O+7quFWwTa58YBD1JQBNmVsuUs4lFNR1Y9jxDKxVdMeJ8JT7ooDVv TEL+UKbUs8Trupkcskai7s3ZP5irTG0wkGPo634vfIGCViVzGC/dH2x7mOlScgWTs+OD 2Mbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XtI4kI7xmiFZKdJhl2L14WuOPVxHEdPjwBT9muXmIkA=; b=SZ8DN+WNDeA0vaTKrIih/0IFbwG9b5A7mVWB40FjiS71GrDJ34ErVWCHuRM7sI5tgy pDKmFpxbK+2eRES9heyPClRXg9C14B7PTZ0DIFI5ouUCb8YZmAXpty7udGLSilYoc2z3 hsqxfbnTwvnx7r9qf3cnwJ4z+FvWn0zNZ7FwzJ8bm3Xo3gjX+DRR1d67rBdxrF36GJnq T6YEO3wWfRE61llPdJudx9purVVtqe8kUne20IeMNtVJkJTcbrFvDJpQDE3+m247pHua FhaQopRxfJb51uVsYnrQpZMgqUQxD8X36KZSILxz5vSUhzDBMJxEIhFjN3p1XnpKwOOu 3HgQ== X-Gm-Message-State: AOAM532adAQdiWfTOrn+kpgvz3T+74W8OogNyy90OTiOKpektQslxQ5s XG3Oq4dd4VMKM3L1vZuCHWa5JFgqSNuqiyPx5gQ= X-Google-Smtp-Source: ABdhPJwWwzGljyFPxbWaVrTQprAtGdjCBXTn6cOS7Qanp9N1IT0yXvf2MuN+sS/KcspUVH5L7l5tbII11acyHXmNd84= X-Received: by 2002:a17:90b:3ec3:: with SMTP id rm3mr6027577pjb.70.1632238867329; Tue, 21 Sep 2021 08:41:07 -0700 (PDT) In-Reply-To: <87czp2c6qd.fsf@gnus.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::102b; envelope-from=joaotavora@gmail.com; helo=mail-pj1-x102b.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 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:275248 Archived-At: On Tue, Sep 21, 2021 at 4:02 PM Lars Ingebrigtsen wrote: > The point here is to not to have any separate namespace, so that you can > just can put core packages into ELPA without doing any rewrites. > > What's the concrete risk here? It was Philip who described as "intrusive", "by its very nature", since it relies on advice and such. This can be seen as "dirty" in itself. But say that the contract/promise that a given function in Emacs 28 makes is different from the promise that the same function in Emacs 24.2 makes. The new ELPA code doesn't have a problem, but you have potential problem to all the other 24.2 code that expects the "old promise". Right? Also macros, defstructs and compile-time/run-time pain, something-something, hand-wavy-wavy, makes my brain hurt :-) > I'm not sure how symbol-renaming would help here? The issue is > providing an "official" forwards-compatibility library that would define > all the useful library functions/macros that are added to Emacs so that > ELPA packages can use these new functions/macros immediately. Symbol renaming could theoretically help by having the new name, say "overlays-at" (I think that's an example of a function that was changed in meaning, may be wrong) be interned as "overlays-at-in-the-emacs-28-sense". The ELPA package author would only write "overlays-at". In that file the redirection would occur when needed. Everywhere else it would be the symbol interned "overlays-at". Alas, symbol renaming for older Emacsen is not in scope for my work (at least right now), so this point may be moot. Jo=C3=A3o