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)
Re: A better name for 'set, a need for a reflection API for SRFI 198?? hga@xxxxxx (16 Aug 2020 13:18 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?? hga@xxxxxx 16 Aug 2020 13:18 UTC

> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Sunday, August 16, 2020 7:41 AM
>
> Am So., 16. Aug. 2020 um 14:30 Uhr schrieb <xxxxxx@ancell-ent.com>:
>>
>>> From: Lassi Kortela <xxxxxx@lassi.io>
>>> Date: Sunday, August 16, 2020 1:31 AM
>>>
>>>> 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.
>>
>> Thus we have incompatible visions for SRFI 198.
>
> I have to admit that I haven't found the time to follow all
> discussions thoroughly (and just looked locally at posts). So could
> anyone of you describe in a few words what the current status of SRFI
> 198 is

The above conflicting visions, with John at least in part agreeing
with mine, need to be resolved.  I think we've discussed the merits,
asked the necessary questions to each other, we cannot reach
consensus, an executive decision by John is needed to move forward.

Ditto for the collections used as inputs, and output for
foreign-status-plist/alist/whatever.  Shall we stick with alists, move
to plists, and for make-foreign-status and raise-foreign-error,
require one of those two, or just have the key/value pairs be optional
arguments, e.g. (raise-foreign-error 'set 'generic-c-lib 'subset
'libsodium etc.).

> and why it is a must for SRFI 170? What is the problem with SRFI 35
> compound conditions, which equally pack various data into an error
> object?

"Above my pay grade."  John?

- Harold