Re: Why should build phases not return unspecified values?

[Pjotr Prins]

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.
--