guix-patches
[Top][All Lists]
Advanced

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

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


From: Ludovic Courtès
Subject: [bug#29745] [PATCH 0/3] Disallow phase returning <unspecified>.
Date: Mon, 18 Dec 2017 09:01:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hello,

Arun Isaac <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> it ends up defining a notion of “true” that’s different from that of
>> Scheme (in Scheme, #f is the only false value; everything else is
>> true, including “the unspecified value”—see “Disjointness of types” in
>> the R5RS.)
>
> I agree. I don't think we should define a new notion of "true" that is
> different from that of Scheme.
>
> But, in that case, why do we explicitly add #t at the end of phases that
> return an unspecified value? Can we not drop this convention and simply
> accept unspecified values from phases as a success of that phase?
>
> The way it is right now, we add #t at the end of phases that return an
> unspecified value, but don't check for this anywhere. So, we have a lot
> of custom phases where people have forgotten to return #t. Patches 2 and
> 3 fix some of these, but I'm sure there are many more. Wouldn't it be
> simpler and more logical to accept unspecified values as "true" in line
> with Scheme's notion of "true"?

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.

I’m not opposed to changing things though.  For instance we could change
the return value of ‘substitute*’ to be #t on success; similarly for
‘install-file’.

What do people think?

Ludo’.





reply via email to

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