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)

Re: Do we have a compatible vision for SRFI 198 Marc Nieper-Wißkirchen 16 Aug 2020 14:23 UTC

Am So., 16. Aug. 2020 um 16:06 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> I believe the question "did this error come from POSIX?" is nonsensical.
> POSIX is not a definite piece of software on a computer. It makes more

+1. I think this remark makes a lot of sense. (I think it is
analogously nonsensically to ask for full implementation of POSIX in
Scheme.)

> The question "did this error come from the C errno variable, and if so,
> which value?" may make sense to ask, but is less useful than the above
> questions and orthogonal to them.

Given that the C code runs parallel with a VM, even this may not be
sensible to ask (see the discussion of SRFI 199).

> I also believe it's wise for 170 to mandate (or at least strongly
> recommend) its errors to have properties that are not wise to require in
> all 198 objects. 170 errors are much easier to understand than the
> universe of all potential 198 objects.

> > I don't see the linkage here.  What would be exotic enough that it
> > can't be represented by all three of the above options? They're all
> > lists of one sort or another.

> By exotic properties I meant ones related SQL, HTTP, IRC and various
> others that are not urgent for SRFI 170.

The closer the error reporting of SRFI 170 is tied to the underlying
system calls (which are actually calls into the C library I think),
the simpler SRFI 170 is to understand.

> > an alist and a plist take the same number of cons cells to collect
> > their key/value pairs (and I note alists are messier for list values).

In what sense are they messier?

PS: Lassi, at some point we should continue with our work on alists.