unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: zimoun <zimon.toutoune@gmail.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
	"Guix Devel" <guix-devel@gnu.org>,
	"Tobias Geerinckx-Rice" <me@tobias.gr>,
	"Josselin Poiret" <dev@jpoiret.xyz>,
	"Mathieu Othacehe" <othacehe@gnu.org>,
	"Christopher Baines" <mail@cbaines.net>,
	"Ricardo Wurmus" <rekado@elephly.net>
Subject: Re: Exception: srfi-35 vs (ice-9 exceptions (was Re: [bug#60802] [PATCH v2 1/2] platforms: Raise an exception when no suitable platform is found.)
Date: Mon, 16 Jan 2023 16:59:02 -0500	[thread overview]
Message-ID: <87r0vu2lax.fsf@gmail.com> (raw)
In-Reply-To: <864jsq8ch1.fsf@gmail.com> (zimoun's message of "Mon, 16 Jan 2023 21:13:14 +0100")

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> On Mon, 16 Jan 2023 at 12:46, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>>> So far the we use (srfi srfi-35) exclusively to define condition types;
>>> I think we should do the same here, for consistency.
>>
>> Could we instead start migrating away from srfi-35 to (ice-9
>> exceptions), which is the new native way to use exceptions in Guile?
>
> Well, I think this should be discussed separately.  Therefore,
> -60802@debbugs.gnu.org and +guix-devel. :-)
>
>
>>                                                                       I
>> think it'd be nicer to use it in the future, to avoid newcomers being
>> confusing about the 3 or 4 ways to manage exceptions in Guile
>> (recommended read on the topic:
>> https://vijaymarupudi.com/blog/2022-02-13-error-handling-in-guile.html).
>
> In Guile maybe several but only one in Guix: (srfi srfi-35). :-)

There are also many old-school catch/throw references too, so that makes
it two!  These can technically be handled using the new style mechanism
too (search for "does-not-exist.txt" in [0]), although that may be too
verbose to be an improvement.

[0]  https://vijaymarupudi.com/blog/2022-02-13-error-handling-in-guile.html

>> Migrating the whole code at once doesn't seem a good idea, so gradually
>> transitioning (such as using (ice-9 exceptions) for new code) appears a
>> good idea to me, if we agree on the direction!
>
> Just to note that all Guix is using (srfi srfi-35); except,
>
> 1 candidates:
> ./guix/build/minetest-build-system.scm:26:  #:use-module (ice-9 exceptions)
>
> Therefore, this plan needs to be a bit cooked, otherwise it will become
> quickly a big mess with 2 ways for managing exceptions – and people, at
> least me, will be confused to pick the correct one depending on the
> module.

If we agree on the direction (gradually moving to (ice-9 exceptions))
and that it provides benefits, I think it could be OK to allow for it to
happen gradually (in new or revisited code at least, say), similar to
the approach we're pursuing for the removal of packages and move to
gexps for the package definitions.  Otherwise the scope for the change
is much higher, and it may never materialize.

> Well, if such migration makes sense (I do not know?), from my point of
> view, the migration of the whole code in a short period of time appears
> to me the best; probably with a dedicated WIP branch.

One benefit would be to reduce the friction in using exceptions in
Guile, which is already higher than in other languages in my opinion
(right now you have to import (srfi srfi-35) and typically (srfi
srfi-34) too just to get started).  Having just (ice-9 exceptions) to
deal with would already be an improvement.  I think technically they are
equivalent (probably the same or very similar) under the hood.

-- 
Thanks,
Maxim


  reply	other threads:[~2023-01-16 22:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230114041903.7121-2-maxim.cournoyer@gmail.com>
     [not found] ` <87o7r19ocn.fsf@gnu.org>
     [not found]   ` <87mt6i5q4q.fsf@gmail.com>
2023-01-16 20:13     ` Exception: srfi-35 vs (ice-9 exceptions (was Re: [bug#60802] [PATCH v2 1/2] platforms: Raise an exception when no suitable platform is found.) zimoun
2023-01-16 21:59       ` Maxim Cournoyer [this message]
2023-01-17 16:35         ` Ludovic Courtès
2023-01-16 22:35       ` Ricardo Wurmus
2023-01-17 19:58         ` Josselin Poiret
2023-01-19 14:38           ` Ludovic Courtès
2023-01-19 15:59             ` Katherine Cox-Buday

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0vu2lax.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=dev@jpoiret.xyz \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=mail@cbaines.net \
    --cc=me@tobias.gr \
    --cc=othacehe@gnu.org \
    --cc=rekado@elephly.net \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).