[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#29745] Why should build phases not return unspecified values?
From: |
Ludovic Courtès |
Subject: |
[bug#29745] Why should build phases not return unspecified values? |
Date: |
Wed, 20 Dec 2017 10:27:16 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Howdy,
Mark H Weaver <address@hidden> skribis:
> I don't think we should rely on every "unspecified value" being treated
> as #true in future versions of Guile. That is merely an accident of the
> current implementation.
>
> However, I also agree that the current situation is a mess in need of
> cleaning up.
>
> My preference would be to deprecate the practice of returning explicit
> boolean results from phases and snippets, and transition to reporting
> errors exclusively using exceptions.
Yes, that sounds more in line with what we usually do.
> We would create a variant of the 'system*' procedure that raises an
> exception in case of a non-zero status code.
Indeed. Like Danny wrote, we can already start migrating to ‘invoke’,
which does exactly that.
> Here's a transition plan: We could start by making the new
> exception-throwing 'system*' variant, and switching existing packages to
> use it, while removing the related error-code plumbing. Once that work
> is done, we could change the code that calls snippets or phase
> procedures to ignore the result of those calls. Finally, we could
> remove the trailing #t's.
>
> What do you think?
That sounds good to me!
Concretely, we can:
1. Encourage use of ‘invoke’ when reviewing or writing new package
definitions;
2. Gradually migrate packages (we can do a bit of that in
‘core-updates’, though we won’t do full rebuilds at this stage).
How does that sound?
Thanks,
Ludo’.
- [bug#29745] Why should build phases not return unspecified values?,
Ludovic Courtès <=