[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] which RxRS?
Re: [Chicken-users] which RxRS?
Tue, 10 Dec 2013 19:24:58 -0500
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
This is not the proper venue for rehashing or ranting about the Scheme
standardization process. And, it's very inappropriate to vilify and
insult other community members. Your original question was answered by
Christian Kellermann. Let's leave it at that, and not start another
- John Croisant
On 12/10/13 7:08 PM, Giorgio Flaverli wrote:
An Olin Shivers-style rant (the Jack'n'Zac one that opens the SCSH
manual) would be extremely tempting given your lack of ability to
comprehend the immense harm that your position brought to the unique
value proposition of Scheme. I've noticed there is little hope arguing
with people like you.
Everytime you introduce a new standard, especially one that is
backwards-incompatible, you split the codebase. Some people will write
R6RS code that is incompatible with R5RS and R7RS implementations.
Some people will write R7RS-large code that is incompatible with R6RS
(and R7RS-small). Now we have R6RS which is even FORWARD-incompatible,
and the 2 R7RS's which are SIDEWAYS incompatible, and you can't see a
problem with this.
This is bad for people who target multiple implementations. Nobody
wants to write 5 versions of code because Chicken, Guile, Racket etc
each decided to target a different standard, or haven't upgraded to
the latest madness from the ADHD-impaired "standardizers" *just yet*.
It's also bad for people who target a single implementation, because
your code that runs today might no longer run a few years later as the
implementation moves on, or the R(x-1)RS support in the implementation
starts receiving less support etc.
2007 was a particularly bad year to split a community and waste
efforts, as Scheme still had a good chance to be adopted for "modern"
stuff (web frameworks, map reduce maybe).
Another problem: anything other than a small standard makes it hard to
write Scheme interpreters "for everything". This was the amazing thing
about Scheme. Want to drive your embedded system? Go ahead and embed a
tiny scheme interpreter. Want to drive JVM code? Use KAWA or Sisc.
Want to drive an Ocaml program? Embed OCS. R7RS-small might be good,
but when lots people write R7RS-large code, and some write R6RS, a lot
of code will be useless to minimalistic implementations.
Finally, it's sad that this whole disaster was fostered upon the
community un-necessarily. There was absolutely nothing wrong with
extending Scheme via the SRFI process, particularly on the library
side. In fact it was an amazingly effective way to assemble a small,
interested community and develop a facility in an organized and
controlled manner (as opposed to having a large "electorate" of
non-experts trample over everything and argue over bike-shed issues
over tens of messages, like a bunch of 'tards).
The fact that most SRFI's had reference implementations **in scheme**
made it extremely easy to add such facilities to a minimalistic
interpreter. In the meanwhile a "big" implementation could write a C
implementation of the SRFI. Programs would simply use
(require-extension (srfi NN)) and not have to care about such details.
Some SRFI's require interpreter support, of course, and users can
pressure implementors to "add SRFI NN support" if it's important to them.
So I don't think my language was excessively harsh. You really have no
idea what you're talking about advocating multiple incompatible
standards and huge incomprehensible standards instead of the concise
"gems" that R5RS and R4RS were. With people like you on the loose a
language can be destroyed (and probably was destroyed, as it's hard to
compete with Python nowadays for any language; back in 2007 there was
still a a chance to focus on software, not on misguided standards).
From: John Cowan <address@hidden>
To: Giorgio Flaverli <address@hidden>
Cc: chicken-users <address@hidden>
Sent: Tue, Dec 10, 2013 7:43 pm
Subject: Re: [Chicken-users] which RxRS?
Giorgio Flaverli scripsit:
> I've gradually lost touch with Scheme after the R6RS debacle. It was
> a sad day to witness the victory of the pushers of complexity, helped
> along by a large number of well-meaning morons who should never have
> been allowed in the "electorate" given that they never even came close
> to implementing a meta-circular. I wonder how much more successful
> Scheme could have been without this disaster and without the harmful
> actions of those individuals who caused it.
This is excessively harsh and downright insulting language. R7RS-small
is, I believe, a substantial improvement over R5RS, but it could not have
been achieved so easily and completely without R6RS first paving the way.
R6RS provided a model of what standards can aim for as well as what they
should not aim for.
For example, the R7RS-small committee adopted the R6RS exception-handling
system unchanged, but rejected the R6RS condition system because it was
backward incompatible with all existing condition systems. The spirit
of the R6RS library system informs that of R7RS, though there are
differences in detail. A vast number of minor R6RS improvements were
added to R7RS-small, leaving out those that we thought would do more to
confuse users than to clarify R5RS.
Although R7RS-large will not be backward compatible with R6RS, and will
be a mix-and-match standard with most components optional, the choices
made in R6RS will continue to influence it.
Lastly, I was one of those who voted Yes on R6RS, not as an implementer (I
am not) but as a user. I favored it not because I thought it was ideal,
but because I thought it was a reasonable compromise. All standards
are compromises, and the purpose of the process is not to produce the
best possible result, but the best result possible in the circumstances.
John Cowan <address@hidden <mailto:address@hidden>>http://www.ccil.org/~cowan
Today an interactive brochure website, tomorrow a global content
management system that leverages collective synergy to drive "outside of
the box" thinking and formulate key objectives into a win-win game plan
with a quality-driven approach that focuses on empowering key players
to drive-up their core competencies and increase expectations with an
all-around initiative to drive up the bottom-line. --Alex Papadimoulis
Chicken-users mailing list