From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: F. Jason Park Newsgroups: gmane.emacs.devel Subject: Re: pcase generates an unprintable expansion for a form in test erc--restore-initialize-priors Date: Mon, 27 May 2024 13:14:58 -0700 Message-ID: <87o78rrozh.fsf@neverwas.me> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23252"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Alan Mackenzie , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 28 04:21:17 2024 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 1sBmSi-0005oF-1Y for ged-emacs-devel@m.gmane-mx.org; Tue, 28 May 2024 04:21:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBmS4-0005BP-Fv; Mon, 27 May 2024 22:20:36 -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 1sBgpZ-00069h-5b for emacs-devel@gnu.org; Mon, 27 May 2024 16:20:29 -0400 Original-Received: from mail-108-mta157.mxroute.com ([136.175.108.157]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sBgpX-00033W-5S for emacs-devel@gnu.org; Mon, 27 May 2024 16:20:28 -0400 Original-Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta157.mxroute.com (ZoneMTA) with ESMTPSA id 18fbbb134a3000efce.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 27 May 2024 20:15:03 +0000 X-Zone-Loop: 9361d6da762f48b44d2069ec83261679bfb59fa6ef07 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fKioecCrO0eY2ooPYE5yJHmI01yMxtumzkomF87esMM=; b=fow9CTgttFAvY5th/4C6aEq0G3 eht/Y4+QbabwTj3AAVDKZgZnUaFBiEXbDje/KqZ1ikFoNDfCifP0oUGCGdoI4y+XJwbfcO2XJ6RkS xZUvSP4P0o2kGOOXHrMXhJtjx2ZuWHCu34PG5WXgJwhtvvLDoaLVXNwVwxlw0gbi1h9pvOaAOs+Q+ SHe3zv9CIsGdwYOnm7dF/S1CXI9tR76pa+eVZZ4D8cJLDg0u8IQxWtPTymg/iEnxbXMbbKcAUAaZS cSQ0PEdzkYbzvkMEBiXCGbGzy3zOqNjAgQb0eQSLy58tWTivwNjMSL6lT8tsLfeRy6PBsZ7I2ATaU 6wrqAkNw==; In-Reply-To: (Stefan Monnier's message of "Mon, 27 May 2024 13:39:47 -0400") X-Authenticated-Id: masked@neverwas.me Received-SPF: pass client-ip=136.175.108.157; envelope-from=jp@neverwas.me; helo=mail-108-mta157.mxroute.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, 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-Mailman-Approved-At: Mon, 27 May 2024 22:20:34 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319638 Archived-At: Hi Stefan, Stefan Monnier writes: > FWIW, I'm wondering what's the value of this specific test. > Do we really care about the specific shape of the returned code? No, we don't care. This test is indeed useless and will be removed. > It seems terribly brittle: every minute change to the macro will require > matching changes to the test, and I have no idea what is the intention > of this test so if it every fails I wouldn't know whether the error is > in the test or in the code. A test _like_ this might make some sense in a case where the code under test is itself deceptively brittle due to being tightly coupled to a dependency, such as the specific shape of another, more complicated macro whose expansion it modifies in ways that aren't easily detectable through behavior alone [1]. In such cases, copying over ("vendoring") the entirety of the complicated "upstream" macro's definition merely to tweak minor aspects, presumably ones that can't easily be overridden or redefined after evaluation, due to side effects, may be deemed a bigger maintenance burden. IOW, after weighing the trade offs, it may be decided such modifications would be better handled through brittle twiddling/surgery during expansion. The point of such a test [2] would then be to "fail fast" so as to alert you to upstream's changes as they happen. Obviously, such a thing should not be done across ownership boundaries. And better practices, like breaking up the complicated dependency into reusable pieces, would be more sustainable long term. Thanks, J.P. [1] https://gitlab.com/emacs-erc/edge/-/blob/fa37e9945df07e8bdb377bd5f5f30d6543521d1e/erc-common.el#L841 [2] https://gitlab.com/emacs-erc/edge/-/blob/fa37e9945df07e8bdb377bd5f5f30d6543521d1e/test/erc-tests.el#L3888