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)
|
array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(02 Oct 2021 18:42 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Alex Shinn
(04 Oct 2021 08:24 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(04 Oct 2021 14:27 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be? Alex Shinn (04 Oct 2021 21:34 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(04 Oct 2021 22:04 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
John Cowan
(04 Oct 2021 22:39 UTC)
|
Re: array-copy, array-stack, array-append: What should the defaults be?
Bradley Lucier
(16 Jan 2022 18:56 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)
|
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