Am So., 30. Juli 2023 um 00:11 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Fri, Jul 28, 2023 at 5:52 PM Bradley Lucier <xxxxxx@purdue.edu> 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.
>
>
> I think that overstates the problem.  If we have a 2 x 2 unsafe matrix M, then the storage object is a 4-element vector V, and so an attempt to access M[0, 2] will try to access a non-existent element of V and raise an exception, unless indeed the storage classes themselves are unsafe.  On the other hand, M[0, 2] will silently access V[2], making M[0, 2] and M[1, 0] the same thing.  In neither case will the Scheme system crash, but the results will be erroneous, and so we should indeed provide a library in which the default is #t.

Why should the Scheme system check the bound of V when asked for a
fast, unsafe version?  Accessing matrix elements could be compiled
into a simple memory fetch.

>
> On Fri, Jul 28, 2023 at 6:19 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>>>
>>>
>> That's a good idea. Since we can't change the default, I would recommend going further: Define (srfi 231), which has the default defined in the SRFI document; (srfi 231 unsafe), which is unsafe; and (srfi 231 safe), which is safe.
>
>
> I don't understand the use of an explicitly unsafe library.  You may be willing to accept unsafe behavior, but it's perfectly reasonable for an implementation of the existing library to always impose safety.  In effect `(srfi 231 unsafe)` is equivalent to `(srfi 231)` behaviorally.
>
>> 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.
>
>
> I would say per contra that all the libraries should expose the same API, but that asking for unsafety in the safe library (or vice versa) should have no effect, and therefore that `array-safe?` always returns true (or false).

I disagree. Nothing forces us to define exactly the same imports for
each of the libraries, and it is better to get a warning about an
undefined identifier ("array-safe?") than exposing non-working
functionality where the user may think that "(array-safe? #t) does
make arrays safe but actually doesn't.