Safe versus unsafe arrays Bradley Lucier (28 Jul 2023 21:52 UTC)
Re: Safe versus unsafe arrays Arthur A. Gleckler (28 Jul 2023 22:19 UTC)
Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen (29 Jul 2023 05:58 UTC)
Re: Safe versus unsafe arrays Arthur A. Gleckler (29 Jul 2023 06:00 UTC)
Re: Safe versus unsafe arrays Bradley Lucier (13 Aug 2023 19:49 UTC)
Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen (13 Aug 2023 19:59 UTC)
Re: Safe versus unsafe arrays John Cowan (29 Jul 2023 22:11 UTC)
Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen (30 Jul 2023 07:41 UTC)
Re: Safe versus unsafe arrays John Cowan (30 Jul 2023 08:46 UTC)
Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen (30 Jul 2023 09:00 UTC)
Re: Safe versus unsafe arrays Bradley Lucier (30 Jul 2023 20:39 UTC)
Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen (30 Jul 2023 20:49 UTC)
Re: Safe versus unsafe arrays John Cowan (30 Jul 2023 21:37 UTC)
Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen (31 Jul 2023 19:49 UTC)
Re: Safe versus unsafe arrays Bradley Lucier (12 Aug 2023 17:58 UTC)
Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen (12 Aug 2023 18:09 UTC)
Re: Safe versus unsafe arrays John Cowan (12 Aug 2023 19:22 UTC)

Re: Safe versus unsafe arrays Marc Nieper-Wißkirchen 13 Aug 2023 19:59 UTC

Am So., 13. Aug. 2023 um 21:49 Uhr schrieb Bradley Lucier <xxxxxx@purdue.edu>:
>
> 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

Looks good to me.

> (srfi 231 unsafe)  ;; Perhaps, with all(?) safety checks removed

Alternatively, leave it to a flag in the Scheme implementation to
compile (srfi 231) to an unsafe library instead.

This can be done by specifying syntax that differs in safe/unsafe
modes of the compiler, say assert (R6RS) or assume (SRFI 145).

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

Looks very good to me.

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

Always wrap the tests in some form (assert/assume, see above) so that
only the behaviour of this form has to be controlled.

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