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

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Arun Isaac <arunisaac@systemreboot.net> skribis:

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

OK, let’s do that in the next ‘core-updates’.

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

True.

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

I agree.

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

I get your point.

I don’t have a strong preference either, to be honest.  I think Mark
did, so I’m Cc’ing him.  Mark?

Ludo’.