On 10/4/21 4:23 AM, Alex Shinn wrote:
> On Sun, Oct 3, 2021 at 3:42 AM Bradley Lucier <xxxxxx@math.purdue.edu> wrote:
>>
>> This led me to think again about
>>
>> (array-copy array [storage-class [mutable? [safe?]]])
>>
>> and the commit message of
>>
>> https://github.com/gambiteer/srfi-179-followup/commit/f2de257e87f341dc1edff0e7b060394bd9960349
>>
>> says that
>>
>> 1.  If the first argument to array-copy is a specialized array, then the
>> values of omitted arguments storage-class, mutable?, and safe? are taken
>> from the first argument, not generic-storage-class,
>> (specialized-array-default-mutable?), and
>> (specialized-array-default-safe?), respectively.
>>
>> So the new array is a true copy of the input specialized array.
>>
>> Any thoughts about what the defaults should be?
>
> I think this is fine - since the name says it is making a copy, it's
> reasonable to copy as faithfully as possible.
>
> The other original procedures returning new arrays are all transforms
> based on specialized-array-share, which also takes mutability and
> safety from the array argument.  Since these are views sharing the
> same underlying storage it arguably makes more sense to share
> these settings than in a copy.
>
> The new procedures array-append and array-stack are special in that
> they take more than one array argument, so the more complex default
> is acceptable.
>
> But I still think it's worth considering making these constants instead
> of parameters, in which case for array-append and array-stack we
> need to revert to your more complex proposed signature.
>

In April you wrote something I now think I didn't understand:

 >> 2. If the default is implementation dependent, then every program, no
 >> matter how it wants default-mutable? and default-safe? to be set, is
 >> going to have to start with calls to
 >>
 >> (specialized-array-default-safe? <whatever>)
 >> (specialized-array-default-mutable? <whatever>)
 >>
 >> which is, in my opinion, unfortunate.
 >
 > Safety is a little vague and implementation-specific to begin with,
 > so it may be OK to leave as a parameter, but I think using such a
 > dynamic parameter at all for mutable? was a mistake.  The default
 > should be built into the constructor procedures themselves.
 >
 > The situation is made worse that these are not explicitly SRFI 39
 > or R7RS parameters.

I responded to this last sentence by making
specialized-array-default-safe? and specialized-array-default-mutable?
parameters, but now I suspect that's not your first choice.

So now, what do you mean by:

 > But I still think it's worth considering making these constants instead
 > of parameters, in which case for array-append and array-stack we
 > need to revert to your more complex proposed signature.
 >

What do you mean "making these constants"?  Implementation-dependent?  I
don't understand.

Brad