Am So., 30. Juli 2023 um 10:46 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Jul 30, 2023 at 3:40 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am So., 30. Juli 2023 um 00:11 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>>
>> 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.
>
>
> Indeed, that is a valid implementation.  The sample implementation, however, does not do so.   Both safe and unsafe arrays are built on top of the same storage classes.

This is a detail of a particular implementation. As Bradley stated in
the initial post, a user may crash their system in the default setting
of SRFI 231.

>> > 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.
>
>
> Come to think of it, the mere fact that the safe library is imported does not mean that all arrays are safe, because a constructor can be imported from the unsafe library.

As soon as one unsafe library is imported into a system, the whole
system is not safe anymore. Think of a library that allows accessing
and modifying any memory address whatsoever.  Thus it is important to
have a version of SRFI 231 that is guaranteed to be safe (and whose
safety cannot be compromised by a switch and without importing an
unsafe library).