[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Arun Isaac
Subject: [bug#29745] [PATCH 0/3] Disallow phase returning <unspecified>.
Date: Mon, 18 Dec 2017 14:36:08 +0530

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]