Am So., 30. Juli 2023 um 00:11 Uhr schrieb John Cowan <[email protected]>: > > > > On Fri, Jul 28, 2023 at 5:52 PM Bradley Lucier <[email protected]> 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 <[email protected]> > 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.
