Am So., 30. Juli 2023 um 10:46 Uhr schrieb John Cowan <[email protected]>:
>
>
>
> On Sun, Jul 30, 2023 at 3:40 AM Marc Nieper-Wißkirchen
> <[email protected]> wrote:
>>
>> Am So., 30. Juli 2023 um 00:11 Uhr schrieb John Cowan <[email protected]>:
>
>
>>
>> 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).
