Am Fr., 4. Dez. 2020 um 23:31 Uhr schrieb Arthur A. Gleckler <xxxxxx@speechcode.com>:

On Fri, Dec 4, 2020 at 2:22 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

I think the basic problem is that there are some situations where R7RS "it is an error" where the situation is not controllable by the programmer. The philosophy should be that errors are signaled (or some other definite (!) action taken) in case interactions with the outside world go wrong, while "it is an error" should be reserved for programming errors. But using `get-environment-variable` is hardly a programming error. And applying `utf8->string` to some user-supplied bytevector should also not count as a programming error.

Would the right thing, then, be to have an SRFI that specifies the error behavior of these various procedures, e.g. exactly what error object is signaled? It seems reasonable to have an SRFI that makes concrete recommendations for what has earlier been covered with "is an error."

If you ask me, I will say yes. It should really belong to R7RS (small) proper, but this cannot be changed retroactively. But the SRFI could be worded in a way that would make it easily integrable into an R7.1RS.

It would be great if there were a clean way to specify that one wanted a replacement character used in these cases. Perhaps using a replacement character could be the new standard behavior except when a parameter is set that means "signal an error instead of using a replacement character."

Just speculating.

That sounds like a good idea. This would make procedures like `command-line` to be dynamic in the sense that they won't always return the same list of strings.

Maybe John knows: Is there a way to encode an arbitrary bytestring in a Unicode string? The problem with the replacement character is that information is lost. I am wondering whether one could set up a meaningful bijection between the countable set of bytevectors and the countable set of Unicode strings.