mutation naming conventions
Alex Shinn
(24 May 2023 02:08 UTC)
|
Re: mutation naming conventions
Marc Nieper-Wißkirchen
(24 May 2023 05:59 UTC)
|
Re: mutation naming conventions
Alex Shinn
(24 May 2023 08:28 UTC)
|
Re: mutation naming conventions
Marc Nieper-Wißkirchen
(24 May 2023 08:53 UTC)
|
Re: mutation naming conventions
Alex Shinn
(24 May 2023 10:10 UTC)
|
Re: mutation naming conventions
Marc Nieper-Wißkirchen
(25 May 2023 16:30 UTC)
|
Re: mutation naming conventions
Shawn Wagner
(31 May 2023 01:09 UTC)
|
Re: mutation naming conventions
Wolfgang Corcoran-Mathe
(25 May 2023 17:35 UTC)
|
Re: mutation naming conventions
Bradley Lucier
(26 May 2023 17:56 UTC)
|
Re: mutation naming conventions
Alex Shinn
(27 May 2023 08:31 UTC)
|
Re: mutation naming conventions
John Cowan
(28 May 2023 22:47 UTC)
|
Re: mutation naming conventions
Alex Shinn
(29 May 2023 00:45 UTC)
|
Re: mutation naming conventions
John Cowan
(29 May 2023 01:26 UTC)
|
Re: mutation naming conventions
Alex Shinn
(29 May 2023 09:35 UTC)
|
Re: mutation naming conventions
Vladimir Nikishkin
(29 May 2023 15:06 UTC)
|
Re: mutation naming conventions Marc Nieper-Wißkirchen (30 May 2023 14:52 UTC)
|
Am Mo., 29. Mai 2023 um 03:26 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > > > On Sun, May 28, 2023 at 8:45 PM Alex Shinn <xxxxxx@gmail.com> wrote: > >> I'm not sure I understand this analogy. What do you mean by safety here? A lazy random array will return different values for every element access to the original array. A copy would produce one snapshot in time of this ever changing array. > > > My point is that you can't tell the difference between an array-copy of such a random-values array (which need not be an array-map, any nonstrict array can behave this way) and an array-copy! of it. A time-consistent snapshot of randomness is indistinguishable from a time-dependent element-by-element copy of it. > >> This seems to be WAI. > > > I don't know what "WAI" is. > >>> >>> A "sufficiently smart compiler" could transform the idiom (array-copy (array-map ...)) to use array-copy! instead. >> >> >> Indeed, but in practice none of the implementations providing SRFI 231 do this now, and such optimizations are fragile > > > I'm not saying it should actually be done, merely that the bad behavior of (array-copy (array-map ...)) can be counted by "Always use (array-copy! (array-map ...)), because there is no demonstrable benefit to using array-copy instead." As long as no impure constructs of the Scheme language are used, there is no difference between (array-copy (array-map ...)) and (array-map ...) except for algorithmic complexity. In general, there is a difference between (array-copy (array-map ...)) and (array-copy! (array-map ...)), though. So the guideline should be: use array-copy! if array-copy is too slow (or takes too much memory) for your use case and if you can control the getters (so that you can prove that array-copy! instead of array-copy makes no difference). IMO, the essential point is not efficiency (because if array-copy is not efficient enough on some implementation, there is array-copy!) but naming. SRFI 231 follows the Scheme tradition (RnRS/SRFI 1) by using a "!" suffix for procedures where attention is needed (because this procedure may not compose well with other features of the Scheme programming language, most prominently its pure subset). Array-copy just works well together with all kinds of other features like algebraic effects, continuable exceptions (and their handler), the amb operator, pure state handlers, etc.; array-copy! doesn't. When translating code from an inferior programming language that does not have any dynamic control features, one can generally use array-copy!.