Re: Why should build phases not return unspecified values?

[ludo@gnu.org (Ludovic Courtès)]

Howdy,

Mark H Weaver <mhw@netris.org> 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’.