[bug#29745] [PATCH 0/3] Disallow phase returning <unspecified>.

[Arun Isaac]

> For instance we could change the return value of ‘substitute*’ to be
> #t on success; similarly for ‘install-file’.

Yes, changing the return value of these functions is a good idea,
regardless of what we decide here in this thread. But, there will always
be phases that do not end with a call to these functions, and we won't
be able to cover those cases. So, this is not a complete solution to the
problem being discussed in this thread.

>> Wouldn't it be simpler and more logical to accept unspecified values
>> as "true" in line with Scheme's notion of "true"?

Also, during patch review, the reviewer has to go to the extra trouble
of manually checking if all phases return #t. If either the build system
strictly checks for #t, or if #t were not strictly required (meaning
#<unspecified> was tolerated), we would save ourselves some tedious
manual work.

> That’s a good question.  My take on it is that it’s clearer: the return
> value of ‘substitute*’ for instance is unspecified, it’s not necessarily
> *the* unspecified value.

My take is that we have two options:

- disallow #<unspecified> and strictly check for #t in the build system
even though this creates a new notion of "true"
- allow #<unspecified> as "true" in line with the rest of Scheme, and
stop appending #t at the end of phases

I have no particular preference about which option we should
choose. But, we do have to choose one of these options
completely. Partial solutions might only add to the existing troubles.