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 12 Aug 2023 18:09 UTC

R6RS defines "safe libraries" and what "safety" means.

Am Sa., 12. Aug. 2023 um 19:59 Uhr schrieb Bradley Lucier <xxxxxx@purdue.edu>:
>
> On 7/28/23 5:52 PM, Bradley Lucier wrote:
> > I have come to regret the choice that initially, to hypothetically speed
> > array operations, the parameter specialized-array-default-safe? is not
> > #t, which would guarantee run-time checks of array getter and setter
> > arguments.  It's not a good look when by default, a library crashes the
> > Scheme system when the programmer makes a mistake.
> >
> > The SRFI document implies, but does not explicitly say, those checks are
> > not in place when an array is created and
> > specialized-array-default-safe? is #f.
> >
> > I'm going to do some performance tests with Gambit's implementation of
> > SRFI 231, which tracks the sample implementation.  If the performance
> > hit is not large, I may set Gambit's implementation to start with safe
> > arrays by default.
> >
> > In a Gambit PR Marc Feeley commented "I would have created 2 variants of
> > the SRFI: (srfi 231) and (srfi 231 unsafe) so that ... by default you
> > get the type checks ..."
> >
> > An interesting idea that would imply a compile-time choice of safe or
> > unsafe arrays instead of a runtime choice at array-creation time.
> >
> > Brad
>
> To maybe move this discussion in a slightly different direction ...
>
> I am not aware of any SRFI or RNRS that talks about "safety" or about
> faster code at the risk of crashing the system in the face of incorrect
> code.
>
> In fact, "safety" seems to be outside the realm of what SRFIs or Scheme
> standards describe.
>
> If SRFI 231 is the first and only SRFI or RNRS to add "safety" to a
> specification, then perhaps that was a mistake.
>
> Brad