Following up on SRFI 179 Bradley Lucier (22 Sep 2021 22:30 UTC)
Re: Following up on SRFI 179 John Cowan (24 Sep 2021 19:24 UTC)
Re: Following up on SRFI 179 Alex Shinn (25 Sep 2021 13:24 UTC)
Re: Following up on SRFI 179 Bradley Lucier (25 Sep 2021 16:43 UTC)
Re: Following up on SRFI 179 Alex Shinn (28 Sep 2021 07:36 UTC)
Re: Following up on SRFI 179 Bradley Lucier (28 Sep 2021 20:20 UTC)
Re: Following up on SRFI 179 Bradley Lucier (28 Sep 2021 20:30 UTC)
Re: Following up on SRFI 179 Bradley Lucier (01 Oct 2021 00:07 UTC)
Re: Following up on SRFI 179 Alex Shinn (01 Oct 2021 00:43 UTC)
Re: array-copy, array-stack, array-append: What should the defaults be? Alex Shinn (04 Oct 2021 21:34 UTC)
Re: Following up on SRFI 179 Lucier, Bradley J (05 Oct 2021 01:04 UTC)
Re: Following up on SRFI 179 John Cowan (06 Oct 2021 01:26 UTC)
Re: Following up on SRFI 179 Lucier, Bradley J (06 Oct 2021 13:48 UTC)
Re: Following up on SRFI 179 Bradley Lucier (05 Oct 2021 19:54 UTC)
array-{append|stack|inner-product} Bradley Lucier (21 Oct 2021 15:52 UTC)

Re: array-copy, array-stack, array-append: What should the defaults be? Alex Shinn 04 Oct 2021 21:34 UTC

On Mon, Oct 4, 2021 at 11:27 PM Bradley Lucier <xxxxxx@math.purdue.edu> wrote:
>
> On 10/4/21 4:23 AM, Alex Shinn wrote:
>
> 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.

Sorry, that was not worded clearly.  By "built into the constructor" I was
suggesting signatures of:

make-specialized-array interval [ storage-class generic-storage-class
] [ safe? #f ]
array-copy array [ storage-class generic-storage-class ] [ mutable? #t
] [ safe? #f ]

where the defaults are specified by the standard and can't be changed.
Note it's easier to remember if the defaults are all #f, so we could change
mutable? to immutable?:

array-copy array [ storage-class generic-storage-class ] [ immutable?
#f ] [ safe? #f ]

or split into separate procedures:

array-copy array [ storage-class generic-storage-class ] [ safe? #f ]
array-immutable-copy array [ storage-class generic-storage-class ] [ safe? #f ]

It's especially mutability which needs to be prescribed by the SRFI or
you lose portability.

The safety setting shouldn't have any effect on a correct program,
so that makes more sense to keep as a parameter.  I don't have a
preference there.  I was just noting that if you want to make it an
object that acts like a parameter it's best to explicitly make it a
parameter.

--
Alex