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