Email list hosting service & mailing list manager

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)

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
adopting it.

Of course, one could finalize a portion of SRFI 170 when it is
understood that it will be later replaced (and deprecated) by an
improved version.

Marc

Am Sa., 15. Aug. 2020 um 14:57 Uhr schrieb <xxxxxx@ancell-ent.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
>