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)

Re: mutation naming conventions Marc Nieper-Wißkirchen 30 May 2023 14:51 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!.