all messages for Guix-related lists mirrored at yhetil.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: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-14  3:05 [bug#60802] [PATCH 0/2] Remove unsupported u-boot-malta package Maxim Cournoyer
2023-01-14  3:08 ` [bug#60802] [PATCH 1/2] platforms: Raise an exception when no suitable platform is found Maxim Cournoyer
2023-01-14  3:08   ` [bug#60802] [PATCH 2/2] gnu: Remove u-boot-malta Maxim Cournoyer
2023-01-14  4:19 ` [bug#60802] [PATCH v2 1/2] platforms: Raise an exception when no suitable platform is found Maxim Cournoyer
2023-01-14  4:19   ` [bug#60802] [PATCH v2 2/2] gnu: Remove u-boot-malta Maxim Cournoyer
2023-01-14 14:34   ` [bug#60802] [PATCH v2 1/2] platforms: Raise an exception when no suitable platform is found Ludovic Courtès
2023-01-16 17:46     ` Maxim Cournoyer
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
2023-01-17  9:22       ` [bug#60802] [PATCH v2 1/2] platforms: Raise an exception when no suitable platform is found Ludovic Courtès
2023-01-14 14:34   ` Ludovic Courtès
2023-01-19  1:55     ` bug#60802: [PATCH 0/2] Remove unsupported u-boot-malta package Maxim Cournoyer
2023-01-14 15:14 ` [bug#60802] [PATCH v3 1/2] platforms: Raise an exception when no suitable platform is found Maxim Cournoyer
2023-01-14 15:14   ` [bug#60802] [PATCH v3 2/2] gnu: Remove u-boot-malta Maxim Cournoyer
2023-01-15 13:57   ` [bug#60802] [PATCH v3 1/2] platforms: Raise an exception when no suitable platform is found Josselin Poiret via Guix-patches via
2023-01-15 22:11     ` Maxim Cournoyer
2023-01-16 11:00     ` Simon Tournier
2023-01-17  8:59     ` Ludovic Courtès
2023-01-17 12:35       ` Simon Tournier
2023-01-17 14:38         ` Maxim Cournoyer
2023-01-17 15:34 ` [bug#60802] [PATCH v4 0/2] Remove unsupported u-boot-malta package Maxim Cournoyer
2023-01-17 15:34   ` [bug#60802] [PATCH v4 1/2] platforms: Raise an exception when no suitable platform is found Maxim Cournoyer
2023-01-17 15:34   ` [bug#60802] [PATCH v4 2/2] gnu: Remove u-boot-malta Maxim Cournoyer

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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.