Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (15 Aug 2020 11:16 UTC)
Re: posix-error and a list of scheme procedure arguments Lassi Kortela (15 Aug 2020 12:09 UTC)
Synthetic errno values Lassi Kortela (15 Aug 2020 13:10 UTC)
Re: Synthetic errno values John Cowan (15 Aug 2020 15:19 UTC)
Re: Synthetic errno values Lassi Kortela (15 Aug 2020 15:34 UTC)
Re: A better name for 'set, a need for a reflection API for SRFI 198?? Lassi Kortela (16 Aug 2020 06:31 UTC)
Re: A better name for 'set, a need for a reflection API for SRFI 198?? Marc Nieper-Wißkirchen (16 Aug 2020 12:41 UTC)
Do we have a compatible vision for SRFI 198 Lassi Kortela (16 Aug 2020 14:06 UTC)
Re: Do we have a compatible vision for SRFI 198 hga@xxxxxx (16 Aug 2020 14:23 UTC)
Decision on foreign-status constructor and accesor syntax Lassi Kortela (16 Aug 2020 14:44 UTC)
Re: Decision on foreign-status constructor and accesor syntax Marc Nieper-Wißkirchen (16 Aug 2020 15:31 UTC)
Re: Decision on foreign-status constructor and accesor syntax Marc Nieper-Wißkirchen (16 Aug 2020 17:19 UTC)
On the messiness of alists for lists as values hga@xxxxxx (16 Aug 2020 17:25 UTC)
Re: On the messiness of alists for lists as values Marc Nieper-Wißkirchen (16 Aug 2020 17:39 UTC)
Re: On the messiness of alists for lists as values hga@xxxxxx (16 Aug 2020 17:52 UTC)
Re: On the messiness of alists for lists as values Marc Nieper-Wißkirchen (16 Aug 2020 18:39 UTC)
Re: On the messiness of alists for lists as values hga@xxxxxx (16 Aug 2020 19:04 UTC)
Re: On the messiness of alists for lists as values John Cowan (16 Aug 2020 22:26 UTC)
PC-Scheme for DOS Lassi Kortela (17 Aug 2020 10:07 UTC)
Re: Do we have a compatible vision for SRFI 198 Marc Nieper-Wißkirchen (16 Aug 2020 14:24 UTC)
Re: Do we have a compatible vision for SRFI 198 John Cowan (17 Aug 2020 02:51 UTC)
Re: Should foreign-status properties be divided into sets or not? Marc Nieper-Wißkirchen (17 Aug 2020 15:51 UTC)
Re: Should foreign-status properties be divided into sets or not? Marc Nieper-Wißkirchen (17 Aug 2020 16:17 UTC)
Re: Should foreign-status properties be divided into sets or not? Marc Nieper-Wißkirchen (17 Aug 2020 16:33 UTC)
Re: SRFI 35 (Conditions), SRFI 198, and do we have a compatible vision Marc Nieper-Wißkirchen (16 Aug 2020 14:14 UTC)
SRFI 35 compound conditions Lassi Kortela (16 Aug 2020 14:23 UTC)
Re: SRFI 35 compound conditions Marc Nieper-Wißkirchen (16 Aug 2020 14:26 UTC)
Re: Synthetic errno values hga@xxxxxx (15 Aug 2020 16:02 UTC)
Re: Synthetic errno values Lassi Kortela (16 Aug 2020 07:58 UTC)
Re: Synthetic errno values hga@xxxxxx (16 Aug 2020 12:39 UTC)
Re: Synthetic errno values Lassi Kortela (16 Aug 2020 13:07 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 01:12 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 02:30 UTC)
Split SRFI 198 from generic debugging/inspection? hga@xxxxxx (16 Aug 2020 02:44 UTC)
Re: Split SRFI 198 from generic debugging/inspection? Lassi Kortela (16 Aug 2020 09:06 UTC)
Re: Split SRFI 198 from generic debugging/inspection? hga@xxxxxx (16 Aug 2020 13:01 UTC)
Matching what other languages give in SRFI 170 errors Lassi Kortela (16 Aug 2020 13:47 UTC)
Re: Matching what other languages give in SRFI 170 errors Marc Nieper-Wißkirchen (17 Aug 2020 06:11 UTC)
Re: Matching what other languages give in SRFI 170 errors Lassi Kortela (17 Aug 2020 10:10 UTC)
Re: posix-error and a list of scheme procedure arguments Göran Weinholt (16 Aug 2020 08:55 UTC)
Re: posix-error and a list of scheme procedure arguments Lassi Kortela (16 Aug 2020 09:02 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 09:11 UTC)
Re: posix-error and a list of scheme procedure arguments Göran Weinholt (16 Aug 2020 09:44 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (16 Aug 2020 10:20 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 11:29 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (16 Aug 2020 12:18 UTC)
Continuation marks and SRFI 198 Lassi Kortela (16 Aug 2020 11:29 UTC)
Re: Continuation marks and SRFI 198 Marc Nieper-Wißkirchen (16 Aug 2020 12:52 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 11:17 UTC)
Passing symbols to say where errors came from? Lassi Kortela (16 Aug 2020 11:21 UTC)
Re: Passing symbols to say where errors came from? John Cowan (17 Aug 2020 17:07 UTC)
Re: Passing symbols to say where errors came from? hga@xxxxxx (17 Aug 2020 18:44 UTC)
Re: Passing symbols to say where errors came from? Shiro Kawai (17 Aug 2020 22:06 UTC)
Re: Passing symbols to say where errors came from? Marc Nieper-Wißkirchen (18 Aug 2020 06:09 UTC)

Re: A better name for 'set, a need for a reflection API for SRFI 198?? Lassi Kortela 16 Aug 2020 06:31 UTC

> I also don't like set, but consider it a placeholder for now, we should
> be able to come up with a better name.
>
> But before going to that effort, we have to agree on the need for it.
> If it's not mandatory, it's a */very/* different thing, and while
> "convention" is a synonym for me in context, "protocol" isn't particularly.

IMHO the purpose of 'set is to give meaning to 'code/number and
'name/symbol. 'code/number and 'name/symbol make sense without 'set, in
the same way that a grammatically correct but taken-out-of-context
sentence makes sense in English. It refers to something definite but
since you lack the context, you don't know what specifically.

In that sense 'set is not technically mandatory yet is obviously useful.

What are we really trying to get to the bottom of -- is this about the
error codes that are non-specific negative integers, where we mainly
know that negative means error and the precise meaning of a particular
number may be unknown?

>> We're gonna need a reflection API at some point (i.e. enumerating sets
>
> What are going to be the consumers of this reflection API?

Mostly Scheme programmers using a REPL or IDE. That implies enumeration
doesn't need to be fast. Python's errno module is prior art:
<https://docs.python.org/3/library/errno.html>.