Note: Please DO NOT send me two replies to this message.

felix wrote:
> There seems to be a tendency in this mailing list that I find
> somewhat distasteful:

Same here. I'm tired of arrogant SRFI authors who not only refuse to
heed criticism, but actually mock their critics. What's the point of
submitting your ideas to a forum like this if you're not actually going
to use it for feedback?

> SRFI-55 is a tiny little thing ....

That's one of the complaints about it. There's no reason to implement it
unless you already provide the functionality, and if you already provide
it, it's just a dumb macro. It doesn't cover any of the subtleties of
existing REQUIRE forms. There's little reason to implement it.

You're not standardizing existing practice; your proposal would require
a name change or an alias in existing Schemes. You're not offering any
advantage over existing practices. What makes your proposal better than
all of the existing solutions? Why should implementors adopt it?

Instead of offering answers to these questions, you're just spewing
venom and making excuses. Don't insult us, convince us.

> Several Scheme implementations (the majority of the serious ones,
> aynway) already provide such a device, so this SRFI is just trying to
> standardize common practice.

No, it isn't. Which Schemes already implement REQUIRE-EXTENSION? Any of
them? Please, quit trying to pass off a brand new name as "common
practice." Extensions that require name changes or new aliases are not
"common practice."

> Now, it seems that some people take this as an opportunity to make big
> statements about million line programs and the dangers to the future
> of Scheme. This is ridiculuous.

They're pointing out that your proposal doesn't actually solve anything,
and that it's incompatible with some systems' requirements. That makes
it technically inferior to existing solutions like SRFI-7. Why bother?

If you're not going to heed criticism, then don't use a forum based on
discussion and criticism. Just publish your extension as a library, or
convince vendors to implement it. If you succeed, standardization should
be easy.

> Moreover, there appears now to exist a common consent among these
> people that I'm just an ignorant, clueless little jerk who doesn't
> know what he's talking about. But I can live with that.

The whining here isn't helping your cause.

> You should have come to the conclusion by now that I can't be
> intimidated by this style of meta-argument ....

You just don't get it, do you? It's not about intimidation.

> Pragmatism and ease of use is important to me, and common practice is
> important to me as well ....

So come up with a proposal that actually represents common practice,
instead of inventing something new and trying to pass it off as common
practice.

> and actual Scheme programmers, who actually produce code, seem to
> prefer the REQUIREish form ....

You keep claiming this, but you still haven't provided any real
evidence.

> (an indication of which is that most Schemes already have some sort of
> REQUIRE, with minor syntactic differences).

You're making a pretty big leap here, concluding that these Schemes
chose REQUIRE-like forms because programmers prefer them. I can think of
at least one other reason that's much more plausible than yours.

> The wonderful thing about the SRFI process is that it allows variety,
> where different designs can compete by "letting the market decide" (so
> to speak), i.e. one can look how well a SRFI gets accepted or not
> accepted.

No, the wonderful thing is that it's an open forum for feedback. This
"letting the market decide" has little to do with the SRFI process;
you'd get the same effect by publishing a library or a new Scheme
implementation.

> So if you don't like it, just ignore it.
> Remember: There is no "danger" in REQUIRE-EXTENSION.

Great, more propaganda. Are you /ever/ going to discuss its technical
merits? Also, has it not occurred to you that poor SRFIs degrade the
whole process? It's no better than any other random web forum unless
there's actually some effort to improve proposed SRFIs and discourage
the poorly-designed ones.
--
Bradd W. Szonye
http://www.szonye.com/bradd