continuable warnings Attila Lendvai (23 Dec 2021 20:26 UTC)
Re: continuable warnings John Cowan (23 Dec 2021 22:31 UTC)
Re: continuable warnings Attila Lendvai (23 Dec 2021 23:03 UTC)
Re: continuable warnings Marc Nieper-Wißkirchen (23 Dec 2021 23:11 UTC)
Re: continuable warnings Attila Lendvai (14 Jan 2023 19:34 UTC)
Re: continuable warnings Marc Nieper-Wißkirchen (14 Jan 2023 19:49 UTC)
Re: continuable warnings Taylan Kammer (23 Dec 2021 22:34 UTC)
Re: continuable warnings John Cowan (23 Dec 2021 22:43 UTC)

Re: continuable warnings Marc Nieper-Wißkirchen 14 Jan 2023 19:48 UTC

Am Sa., 14. Jan. 2023 um 20:34 Uhr schrieb Attila Lendvai <xxxxxx@lendvai.name>:
>
> > > Common Lisp has a SERIOUS-CONDITION type to communicate that it's something that must be dealt with, and if no one else handles it, then the toplevel must enter the debugger, or quit the process when the debugger is disabled.
> >
> >
> > It is &serious in R6RS. You can test it with "serious-condition?". The
> > initial exception handler of an R6RS system should return on all
> > non-serious conditions (see 7.1 of the R6RS Scheme Libraries), so it
> > makes sense for SRFI 64 to deal with serious/non-serious conditions
> > similarly.
>
>
> any news on this? any chance someone more experienced than me will get to implement this?

Guix uses Guile, doesn't it?

If so, I would improve Guile's implementation of SRFI 64.  Check all
occurrences of `guard' and add `serious-condition?' checks.

>
> or am i on my own to work my way towards a PR?
>
> the issue tracker is disabled on github, i cannot record this anywhere else than this list.

This is the right place.

>
> --
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “A computer is like an Old Testament god, with a lot of rules and no mercy.”
>         — Joseph Campbell
>