Email list hosting service & mailing list manager

Fate of this SRFI Daphne Preston-Kendal (09 Apr 2023 12:06 UTC)
Re: Fate of this SRFI Arthur A. Gleckler (09 Apr 2023 17:14 UTC)
Re: Fate of this SRFI Lassi Kortela (20 Apr 2023 12:26 UTC)
Ramifications for the future Lassi Kortela (20 Apr 2023 13:18 UTC)

Fate of this SRFI Daphne Preston-Kendal 09 Apr 2023 12:06 UTC

Hello all,

This SRFI appears to be stuck.

I think it should be withdrawn without finalization and without replacement for the following reasons:

1. Reading #< in R7RS small is already erroneous: this merely tightens this to a ‘signals an error’ situation. The utility of this change in the context of the small language is not clear; in the context of the large language, it’s a tiny proposal which could just as well be dealt with in a Codeberg issue, but is also a proposal that needs to wait until the bigger picture of error strictness and condition hierarchies etc. is finally resolved for the large language. (I think we have more or less settled on an R6RS-like condition system, but I would like most errors to be restartable in the sense of Common Lisp which is a change compared to R6, and to what extent we want to require certain errors to be signalled in particular situations is also unclear.)

2. The idea to have a way to recover data from an ‘unreadable’ #< value is novel, but fundamentally flawed as detailed in previous mailing list posts. The issue with the ambiguity of > might possibly be solvable if this SRFI switched to, say, #[] as the notation for ‘unreadable’ values, but even then, there’s a reason these values, especially procedures, are unreadable – and this SRFI cannot work around those problems.