Re: [Chicken-users] which RxRS?

[.alyn.post.]

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/