posix-error and a list of scheme procedure arguments Shiro Kawai 15 Aug 2020 07:54 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 15 Aug 2020 10:57 UTC
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 hga@xxxxxx 15 Aug 2020 11:50 UTC
Re: posix-error and a list of scheme procedure arguments Lassi Kortela 15 Aug 2020 12:09 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 15 Aug 2020 12:42 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: 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:11 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 16 Aug 2020 02:26 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:43 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:52 UTC
Re: posix-error and a list of scheme procedure arguments Lassi Kortela 16 Aug 2020 09:01 UTC
Re: posix-error and a list of scheme procedure arguments Shiro Kawai 16 Aug 2020 09:10 UTC
Re: posix-error and a list of scheme procedure arguments Göran Weinholt 16 Aug 2020 09:40 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:51 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:06 UTC
Re: Passing symbols to say where errors came from? hga@xxxxxx 17 Aug 2020 18:43 UTC
Re: Passing symbols to say where errors came from? Shiro Kawai 17 Aug 2020 22:05 UTC
Re: Passing symbols to say where errors came from? Marc Nieper-Wißkirchen 18 Aug 2020 06:09 UTC

Re: Split SRFI 198 from generic debugging/inspection? hga@xxxxxx 16 Aug 2020 13:01 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, August 16, 2020 4:06 AM
>
>>> [ Shiro on scoping: ]
>>>
>>> My intention is rather to split srfi-198 from generic
>>> debugging/inspection interface (but not assuming the latter is
>>> possible).  Specifically, scheme-procedure and args optional (at
>>> least for srfi-170).
>>
>> Ah, yes, that goal makes complete sense.

Although we might state a requirement, or it is "strongly suggested",
that if the environment doesn't allow you to find out the Scheme
procedure throwing an exception, the status object it throws must
include it.

> I also agree that Shiro's advice is wise. Let's make the procedure and
> argument info optional in SRFI 170 (and naturally in 198 as well).

My concept is something like this:

required by SRFI 198: 'set
required by e.g. SRFI 170: ??, but fewer than the current required
"strongly suggested" by SRFI 198: 'message, 'foreign-interface, ??
"strongly suggested" by e.g. SRFI 170: ??
"nice to have, and we have a Schemeregistry standard": 'heritage

The last is to e.g. tell a user of R7RS-large into which SRFI 170 has
been assimilated where he might look to find historical information.

For example, the SRFI doc of course does not explain why all of the
particular decisions were made about its API.  But someone wondering
why so many but not all SRFI 170 file system procedures take only a
string filename can search the archived discussion and discover the
reason was to lessen the burden on implementors using the 80/20
Pareto Principle as a guiding principle.

>> [...]

- Harold