> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de> > Date: Monday, August 17, 2020 10:51 AM > > Following this argument, wouldn't it be enough for SRFI 170 to define > the following procedures: > > (posix-error? obj) -> boolean > (posix-error-errno posix-error) -> symbol > (posix-error-message posix-error) -> string > (posix-error errno message) -> exception > > With these procedures, SRFI 170 would be independent of SRFI 198 and > could be finalized independently. While there are objections to them for Scheme implementations that have real debugging capabilities, there are additional ones however you get them, specifically: 'scheme-procedure, which one made the raise call 'foreign-interface, which POSIX function reported an error (and that requires a lot more out of a debugger) 'args, the arguments the Scheme procedure was called with > SRFI 198 can later implement these four procedures in terms of its > foreign error objects and specify some mapping that has to be obeyed > for systems supporting SRFI 170 and SRFI 198. We for example might want to add posix-error-keys, which is just foreign-error-keys, and in the same way posix-error-ref to mirror foreign-error-ref for the above keys, and keys we haven't yet thought of. For example, I don't want to limit the options of future SRFI 170 implementors. Required keys? Certainly? No additional ones ever...? Strictly limiting the data you can get from a raised error is very much not in the spirit of SRFI 198, although it fits the scsh errno-error procedure that started this whole saga. - Harold > Am Mo., 17. Aug. 2020 um 17:39 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: >> >> Just a quick note... Many programming language's OS API effectively >> gives you 'errno (a symbol) and 'message (a string). >> >> If SRFI 170 says: >> >> - all errors are raised as SRFI 198 foreign-status objects >> >> - The implementation should work hard to fill in the 'errno and 'message >> properties whenever possible. 'errno can freely be synthesized from >> other operating system's similar errors, but should not be entirely >> fantastical just for the sake of having it present. >> >> ...wouldn't that get us everything we urgently need and most languages >> give, with minimal effort and minimal restrictions on the final form of >> SRFI 198. >> >> If we have a property named 'errno, it makes no sense to put anything >> other than C/POSIX/Unix errno compatible values in it. Anything else >> would confuse people. Likewise, C/POSIX/Unix errno numbers are not >> portable, so clearly the value should always be symbolic (ENOENT etc.) >> instead of numeric. >> >> If we have a property named 'message (or 'text), it makes no sense to >> put anything other than a human-readable string in there. We can't >> guarantee that an English message is available in the general case, so >> 'message can be whichever localization is at hand. We can later add a >> separate 'localize-message or something to deal with that -- it doesn't >> have to be SRFI 170's concern.
