Re: Why should build phases not return unspecified values?

[Andy Wingo]

On Sun 17 Dec 2017 00:28, Arun Isaac <address@hidden> writes:

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

I agree entirely.

IMO the continuation of a build phase should be:

  (define build-phase-cont
    (case-lambda
      (() #t)
      ((ret . _) (and ret #t))))

I.e. the phase could return 0 values, that's fine, we count as success.
Quite possible if your build phase ends up tail-calling to some
procedure you don't care about which returns 0 values for its own
reasons (arguably nicer than returning "the unspecified value", blah);
currently this doesn't work though.  Similarly for build phases that
return more than 1 value; extra values should be ignored (this is
currently the case).  Making a build phase return a single boolean value
in a language like Scheme is busy-work IMO.

Andy