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 12:42 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Saturday, August 15, 2020 7:09 AM
>
> [...]
>
>>> 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.

I believe both John and I are convinced we should require the triple
of 'scheme-procedure, its 'args, and 'foreign-interface (at least the
latter is easy in Shiro's signaling an error at the C level scenario).

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

Except this is a tightly specified SRFI.  One problem comes with
Shiro's scenario where a C level primitive that's not only called by
SRFI 170 (or in the long term, any of the other POSIX SRFIs that
extend it), and therefore 'set is unknown, although 'errno, which I'm
vastly preferring for the key for the errno raw integer, *can* have a
legitimate value.

> But they must always fill in an 'errno property with the
> errno-equivalent symbol where such is known.

Urg for namespacing, but, yes, it's probably not much of an imposition
to also report the C define name as a symbol, e.g. 'ENOENT under
whatever key we decide for the POSIX errno 'set.

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

I really dislike lying to the user.  Perhaps justifiable here, but....

> As explained in another thread, I wouldn't use a 'set property to
> indicate success vs failure from negative vs nonnegative return values.

Set just tells you the slice of the status and error universe the
object is in, and ideally it'll be registered in the Schemeregistry.

Unless you use the generic reserved values of 'error or 'status (and
even then you could lie in using them), it says absolutely nothing
about whether the foreign status object represents success or failure,
unless by convention all status in that set are one or the other, which
is true for the POSIX errno 'set.

If not, that would be the job of a standard key inside it.  Perhaps common
enough to be added to the Standard set conventions at the end of SRFI 198.
The 'success? key you suggest below sounds good.

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

And here I say for the last point you make above, use 'set with either
'error or 'status as the value to signal that the status object is *not*
one of those "coherently defined set[s] of particular error values."

Which could actually save a lot of effort by telling people, don't
look to the Schemeregistry to figure out what the additional keys mean,
read the documentation or source code that's using SRFI 198 in this
very generic way.

- Harold