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: posix-error and a list of scheme procedure arguments hga@xxxxxx 15 Aug 2020 11:50 UTC

> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Saturday, August 15, 2020 6:16 AM
>
> Am Sa., 15. Aug. 2020 um 12:58 Uhr schrieb <xxxxxx@ancell-ent.com>:
>
>> The theory I've been working on is that it's the responsibility of
>> the calling Scheme procedure to catch such thrown errors and turn
>> them into proper SRFI 170 errors.  Like too many other details,
>> I've fudged this for the SRFI 170 Chibi Scheme sample
>> implementation, its automagic FFI only throws type check errors, I
>> just mechanically duplicate that checking in the calling Scheme
>> procedure.  An error like EPERM, which of course can only be
>> detected at the C level, is done through an error return value and
>> then (improper) querying of errno.
>>
>> Having 'scheme-procedure be #f deprives the user of valuable
>> information that could make debugging quite a bit harder, although
>> if you fake the values for the 'args key it probably won't be too
>> bad.
>>
>> One alternative that occurs to me is that you could pass to the C
>> code the calling Scheme procedure, or as you note, examine the
>> stack to get that and the args.
>
> Depending on the implementation there may be no stack entry. And you
> probably don't want the overhead to pass the called Scheme procedure
> and its arguments in the generic case where there is no error.

I agree with the latter point, it's weighing down each call just in
case an error is detected.

> The information about the called procedure and its arguments is
> certainly useful for debugging, but it is probably best to leave it up
> to the implementation how (and if) this information is provided (at
> least until we have some general consensus about debugging
> facilities).

Disagree on the "and if", I don't think an implementation will be
providing enough useful information if it doesn't provide that basic
information.  It's still explicitly allowed, ed style "?" errors
without, well, I suppose any keys in Lassi's conception.  In my
conception including example code, they'd have 'status or 'error
as the value of the 'set key, and require *nothing* else in the object.

Is it really a grave imposition on the programmer using SRFI 198 to
have to supply one of those two generic reserved 'set values if he
just wants to get the job done, doesn't for example want to go to the
trouble of registering an error set with Schemeregistry??

Note also I plan to carve out some very genetic 'set values, like
genetic-unix-lib, which would only require the keys 'scheme-procedure,
'foreign-interface, 'message, and 'args.  SQLSTATE is also a good
candidate for this.  But of course we can't require the user of SRFI
198 to bother checking Schemeregistry before using SRFI 198.

- Harold