[Scheme-reports] a call for peace Alex Shinn (26 May 2011 11:53 UTC)
Re: [Scheme-reports] a call for peace Jim Wise (26 May 2011 14:17 UTC)
Re: [Scheme-reports] a call for peace Alaric Snell-Pym (26 May 2011 17:11 UTC)

[Scheme-reports] a call for peace Alex Shinn 26 May 2011 11:53 UTC

I've been procrastinating writing this ever since the group
formed, but recent debates and rising tempers on the list have
shown it really can't wait.  We need to update the background
and introduction in a way that people can understand the purpose
of this effort.

What happened with R6RS was a tragedy.  A huge amount of work
was put into the last standard, and while many improvements were
made, there were a lot of changes overall, including some very
controversial ones.  Moreover, the style of the report changed.
Earlier reports were extremely conservative, mostly summarizing
the de-facto behaviors of major implementations.  They were not
shy to leave many aspects of the semantics unspecified, even
going so far as to add notes about possible non-standard
extensions in the document itself.  R6RS, on the other hand and
in the interest of increased portability, chose to specify most
of the behavior that previous standards left unspecified, and
required errors to be signalled in many situations.

The result was a factioning of the community.  Many people not
directly involved took it upon themselves to write the
self-introduction necessary to register for the electorate, to
write the required rationale for a "no" vote, and to vote
against ratification - enough so that the R6RS was barely able
to achieve the 65% majority needed for ratification.  Even after
it passed there was lackluster uptake, and many implementors
outright refused to support it.

We are very broadly split into the R5RS camp and the R6RS camp,
with every shade of gray in between.  Both sides have good
points.  We could go through a list of differences and choose a
compromise for each one, but that would make both sides unhappy.

So to bridge the two communities, the new standard was split
into two languages - a "small" language to attract the R5RS
camp, and a "large" language to attract the R6RS camp - with the
requirement that the two languages be consistent.  This would in
theory make everyone happy, provide an easy transition in both
directions, and allow users of both languages to share as much
code as possible.

The current draft under discussion is the "small" language.
This is the language to appeal to the R5RS camp.  To come into
the discussion now and condemn the draft for not being R6RS is
missing the point.  Yes, any given change from R6RS is a
candidate for inclusion in this language, but the default is
strongly R5RS.  The change can always be included in the "large"
language.  If we just include everything in the small language
there's no point in having two languages, and neither language
would appeal to the R5RS camp.

If you disagree that there should be two languages at all, then
I recommend you to pick the language you want and ignore the
other.  Attacking the language you don't like only strengthens
the divide in the community, antagonizes the WG members, and
ultimately makes it less likely any changes you want will be
included.  Worse, attacking WG members is just childish.  This
is not a contest, and ultimately no one will remember or care
who "wins" or "loses" a debate on the list.

We look forward to all the constructive criticism the community
can provide, and promise to take your ideas seriously, even if
they ultimately do not get accepted.  But if you have no
interest in contributing constructively, then please keep your
heckling to yourself.

Thank you,
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports