On 7/29/23 2:00 AM, Arthur A. Gleckler wrote:
> ---- *External Email*: Use caution with attachments, links, or sharing
> data ----
>
>
> On Fri, Jul 28, 2023 at 10:58 PM Marc Nieper-Wißkirchen
> <xxxxxx@gmail.com <mailto:xxxxxx@gmail.com>> wrote:
>
>     I would provide a version (of SRFI 231) with no safe? parameter
>     because everything is safe. The current consensus on the large
>     language is that it is safe in the sense that one mustn't be able to
>     crash the system by calling procedures of the standard libraries.
>     Should SRFI 231 become part of the large language, only the version
>     without the safety parameter should be used.
>
>
> Yes, and while we're waiting for R7RS Large, you could omit the
> parameter from the |(srfi 231 safe)| and |(srfi 231 unsafe)| libraries,
> leaving it only in |(srfi 231)| for conformance.

OK, now I understand.  If SRFI 231 is adopted for R7RS large, then there
could be something like

(srfi 231)         ;; default library, always safe
(srfi 231 unsafe)  ;; Perhaps, with all(?) safety checks removed

Neither would have the specialized-array-default-safe? parameter, or the
safe? optional arguments to the routines that return specialized arrays.

Currently, the parameter specialized-array-default-safe? determines only
whether a specialized array's getter and setter check their arguments,
not whether arguments to other procedures are checked for correctness;
in the sample implementation all other arguments are checked for
correctness.

Should (srfi 231 unsafe) abandon all error checks on procedure
arguments?  In my experience it would be nearly impossible to develop
code with a library like this, but perhaps someone might like to
distribute "debugged" code like this.

I don't know how to package three different libraries

(srfi 231)        ;; current library
(srfi 231 safe)   ;; without safe? parameter or arguments
(srfi 231 unsafe) ;; also without safe? parameter or arguments

Perhaps it's not so important right now.

Brad