Re: Why should build phases not return unspecified values?

[Alex Vong <alexvong1995@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

Arun Isaac <arunisaac@systemreboot.net> 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?
>
> WDYT?

I think the problem is that when the scheme standard says "the returned
value is unspecified", it means anything can be returned. In this case,
guile choose to return an unspecified value to avoid returning an
arbitary value.

I think the answer written by soegaard in [0] explains it pretty well.

[0]: https://stackoverflow.com/questions/28910911/detecting-unspecified-in-scheme-list

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]