Re: What real harm would be caused by gating finalization of SRFI 170 on finalization of SRFI 198? Marc Nieper-WiÃkirchen 15 Aug 2020 13:06 UTC
If you ask me, we don't have to finalize anything until R7RS-large is
declared final. :)
Especially for such a complex SRFI like this one, issues will continue
to pop up when its usage increases and more implementations are
Of course, one could finalize a portion of SRFI 170 when it is
understood that it will be later replaced (and deprecated) by an
Am Sa., 15. Aug. 2020 um 14:57 Uhr schrieb <email@example.com>:
> Real harm includes emotional discouragement, we've worked very hard on it (most I've done in years), polished it as much as is practical and I believe to a high degree, and we want to get this 15 month long and counting project done and over with.
> But outside of that, what harm will be done to the community, the next block of work on R7RS-large, etc., if we just set it to the side and then update section 3.1 Error handling to be "perfect", or at least perfectly aligned with a finalized SRFI 198??
> This strikes me as being a bit related to the fallacy of sunk costs, at least in what may be driving us to get it done.
> We could also (in)formally declare it to be finalized except for section 3.1 Error handling....
> - Harold