Am Tue, 06 Jan 2004 11:56:48 +0100 hat Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> geschrieben:

>
> 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