I’m not going to act hastily, however. The process for the previous SRFI-122 (you mention SRFI 150, but I think that’s a misprint) made me realize how unprepared I was when I first sent in the proposal, so I want to think about this for a while before adding an “addendum” SRFI proposal with procedures that I think should have been in SRFI-122 in the first place. (I can’t imagine any other than array-assign! at the moment, but that has changed in the past.)
On Jan 31, 2017, at 6:24 PM, Arthur A. Gleckler <firstname.lastname@example.org> wrote:On Mon, Jan 30, 2017 at 1:25 PM, Bradley Lucier <email@example.com> wrote:I've set something up in
and generated a pull request. You may not be able to use it as is, but perhaps it's something you can start with.
Tell me if you'd like something different.
Thanks very much. I've spent a while looking over it, and while it looks good, it is a non-erratum change to the document after it has been finalized, which isn't supposed to happen. I've already stretched the official SRFI process by adding an erratum process, and I'm nervous about setting a precedent of allowing changes beyond simple bug fixes.Would you mind creating SRFI 151 for array-assign!? It's perfectly okay for it to be short, including just what you added in your draft amendments to 150. Once it has been finalized, I will add a post-finalization note to 150 pointing to 151. We can include the full implementation in 151. That way, no one will have any trouble finding it.Thanks.