Email list hosting service & mailing list manager

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 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: 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 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 Lassi Kortela 15 Aug 2020 12:09 UTC

>> 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.

+1

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

+1

> 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.

For always guaranteeing to find the calling Scheme procedure, I'd make
that optional so we can ship 170 without a giant delay.

As far as I can tell, we could solve the errno problem for SRFI 170 by
letting the implementor return a foreign-status object with any 'set
they want (or no 'set at all, which is the same as #f). But they must
always fill in an 'errno property with the errno-equivalent symbol where
such is known.

We could provide a mapping of Windows API error codes to errno values in
the sample implementation. Python already does such a mapping in its os
module I think.

As explained in another thread, I wouldn't use a 'set property to
indicate success vs failure from negative vs nonnegative return values.
Infinite sets are not enumerable so those are not really error codes. I
would just return a 'success? property that is #t or #f, which gives the
same information. If we want to return the precise return value as well,
I'd return it in 'number (aka 'code) but leave out the 'set unless it
really belongs to a coherently defined set of particular error values.