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?? 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)

Decision on foreign-status constructor and accesor syntax Lassi Kortela 16 Aug 2020 14:44 UTC

>> By exotic properties I meant ones related SQL, HTTP, IRC and various
>> others that are not urgent for SRFI 170.
>
> But those are items *collected* in the three different types of lists,
> right?  Alists, plist, optional arguments at the end of a procedure's
> signature are just equivalent ways to collect key/value pairs.  Except
> for the trickiness lists as values for alists.

Ah, I didn't realize you were talking about which constructors and
accessors we should have. I agree that they are equivalent.

I strongly recommend that `make-foreign-status` and
`raise-foreign-status` take a plist, for the simple reason that keyword
argument lists look just like plists. In Scheme implementations with
keyword objects, we can convert keywords to symbols when they are plist
keys. That lets us transparently switch these procedures to a
keyword-based syntax in case keywords are ever standardized in Scheme.

As for whether `foreign-status-keys` or `foreign-status-plist` or
`foreign-status-alist` should exist, that's less important still. The
main concerns are that 1) returning all values at once forces the
evaluation of all lazy lambdas if we have such things; 2) alists have
`assoc` in RnRS whereas plists don't.

> Not sure about the args at the end of a procedure's
> arguments option, it looks like an implicit plist to me.

They are :)