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. 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).
