This page is part of the web mail archives of SRFI discuss from before July 7th, 2015. The new archives for SRFI discuss contain all messages, not just those from before July 7th, 2015.
The way the discussion is going, I feel compelled to put on my editor's hat for a moment. If you'll indulge me, pretend, for a second, that I'm not a co-author of this SRFI.
Hm. That's not that easy. I'll try... ;-)
Some of you are pretending that writing a SRFI comes with some kind of obligation to fulfill certain goals you think are implied by its title, or that the SRFI somehow implies a certain opinion or view. In fact, no such obligation exists outside of what the editors determine, and the SRFI represents a suggestion rather than a view. Instead, authors of SRFIs are providing a *service*. If you make use of this service or not is entirely up to you. If you don't like the service, ignore it or provide another. That's what the SRFI process is for. If you're unhappy about that, post on srfi-discuss.
So why have a public discussion and a draft period? Discussions can get heated, that's nothing one should be afraid of. It just shows that everybody takes the issues seriously. I've seen much worse. The service that is provided is something that I'm grateful for, and I consider it a herculean task to design a SRFI and put it up for discussion here, with all those whacko implementors sharpening their knives, dribbling, waiting to pounce on you... But you should also realize that SRFI-50 touches a *very* sensitive area here - an area where you directly fiddle with implementations internals (either directly or indirectly). So some people may be pretty concerned. I think this is a great opportunity to provide an (mostly) implementation independent way of interfacing with that tasty stuff out there. This is extremly exciting. But why exclude implementations that don't follow the "simple" (and that is not meant in the derogative) model? There is also a certain problem with semi-standard designs like SRFIs: once something gets finalized and owns a "semi-standard" status (wether justified or not), someone will use it. And you quickly end up with a "fait accompli", where an inferior design is gaining more and more ground, just because it's there. So why don't put some hard work into getting it right from the start?
Therefore, wordings like (I'm approximating here) "wasted SRFI" or "we must reject the approach taken in the draft" are entirely uncalled for, and not helpful in the discussion---especially, as they're likely to annoy the authors and get you away from the goal of convinving them to change the draft, rather than closer to it.
I don't think it's quite that bad. On the other hand, the authors haven't shown much effort to address many of the issues others have pointed out, and wordings like (I'm approximating as well here) "we don't care, that's the way we like it" don't really improve the situation. This is a public discussion, one should be allowed (hopefully purely with technical reasons) to comment on it. Not in the sense "this must be rejected at all costs", but in the sense of "hey guys, you're making a mistake here: this and that of your proposal has a couple of problems. I would do it like this...", and people already have done so (most notably Tom Lord).
Now, putting on my author's hat back on, neither Richard nor I have offered this SRFI *draft* as the final word on anything. Right now, we're trying to understand the issues. Burying them under lots of opinionated language (whether the opinions are justified or not) isn't going to help.
Right. But opinions is what a discussion is about, mostly, no? cheers, felix