From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: Why should build phases not return unspecified values? Date: Sun, 17 Dec 2017 08:03:13 +0100 Message-ID: <20171217070313.GA21785@thebird.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQT1U-0001Xp-68 for guix-devel@gnu.org; Sun, 17 Dec 2017 02:06:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQT1P-0003u8-ER for guix-devel@gnu.org; Sun, 17 Dec 2017 02:06:08 -0500 Received: from mail.thebird.nl ([95.154.246.10]:41422) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eQT1P-0003kq-86 for guix-devel@gnu.org; Sun, 17 Dec 2017 02:06:03 -0500 Content-Disposition: inline In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Arun Isaac Cc: guix-devel@gnu.org On Sun, Dec 17, 2017 at 04:58:15AM +0530, Arun Isaac wrote: > > Whenever we have a build phase that ends with a call (for example, to > substitute, chdir, symlink, etc) that returns an unspecified value, we > append a #t so that the return value is a boolean. However, the build > system, as it stands currently, does not mind an unspecified value, and > treats it as a success. As a result, forgetting to add a #t at the end > of custom phases is a common mistake. To fix this, I have submitted a > patch at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29745 that > modifies the build system to reject unspecified values as > failures. > > However, IMO, the addition of #t at the end of certain phases, does not > contribute anything of value and we should simply be at peace with > phases returning unspecified values. Am I missing something here? If an unspecified value is treated as #t I would prefer allowing an unspecified value. The less visual 'noise' we have the better. The build will break if something goes wrong. But then in strictly typed languages you would need to be explicit... It is a matter of taste in the end. I have wondered why I would need to put in a #t there. Pj. --