[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] which RxRS?
From: |
.alyn.post. |
Subject: |
Re: [Chicken-users] which RxRS? |
Date: |
Tue, 10 Dec 2013 17:26:52 -0701 |
Are there more appropriate mailing lists you could have this
discussion on? Would you like some help with Chicken Scheme?
-a
On Tue, Dec 10, 2013 at 07:08:19PM -0500, Giorgio Flaverli wrote:
> @John Cowan;
>
> 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).
>
> -----Original Message-----
> 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> [2]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
>
> References
>
> Visible links
> 1. mailto:address@hidden
> 2. http://www.ccil.org/~cowan
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-users
--
my personal website: http://c0redump.org/