[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: question regarding substitute* and #t
From: |
Arun Isaac |
Subject: |
Re: question regarding substitute* and #t |
Date: |
Thu, 25 Jan 2018 14:01:13 +0530 |
Mark H Weaver <address@hidden> writes:
> After we switch to using 'invoke' everywhere, or more precisely, after
> we arrange to never return #false from any phase or snippet, then
> there should be one more step before removing the vestigial #true
> returns: we should change the code that calls phases or snippets to
> ignore the value(s) returned by those procedures. When that is done,
> then the #t's will truly be vestigial. Does that make sense?
I think we should start removing the vestigial #true right away. Why
wait until we can make the code that calls phases ignore the values
returned by those phases? As it stands, that code errors out only when a
phase returns #false, not when it returns any other value (even
unspecified). WDYT?
The #true is already vestigial. In fact, #true being vestigial is what
annoyed me and made me start the original thread discussing ways to get
rid of it.
https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00235.html
And, it so happened that we concluded the best way to go forward was to
deprecate boolean results altogether and transition to an exception
based system.
- Simplifications enabled by switching to 'invoke', Mark H Weaver, 2018/01/24
- question regarding substitute* and #t (was: Simplifications enabled by switching to 'invoke'), Andy Wingo, 2018/01/24
- Re: question regarding substitute* and #t, Mark H Weaver, 2018/01/24
- Re: question regarding substitute* and #t, Andy Wingo, 2018/01/24
- Re: question regarding substitute* and #t, Kei Kebreau, 2018/01/24
- Re: question regarding substitute* and #t, Maxim Cournoyer, 2018/01/25
- Re: question regarding substitute* and #t, Andy Wingo, 2018/01/25
- Re: question regarding substitute* and #t, Maxim Cournoyer, 2018/01/25
- Re: question regarding substitute* and #t,
Arun Isaac <=
- Re: question regarding substitute* and #t, Mark H Weaver, 2018/01/25
Re: question regarding substitute* and #t, Hartmut Goebel, 2018/01/24