On Wed, 2009-02-18 at 11:05 -0500, Matthias Felleisen wrote: > On Feb 18, 2009, at 3:04 AM, [email protected] wrote: > > > Message: 11 > > Date: Wed, 18 Feb 2009 00:04:00 -0800 > > From: Thomas Lord <[email protected]> > > > Posted at http://blog.plt-scheme.org/ > > Sorry for the remnants of html -- Matthias
I think you are hinting at an argument for a different slate that what I'm endorsing but I think the slate I'm suggesting meets your criteria. I think your concerns are legit - I just don't think they're accurate. There's no need here to "overturn R6RS" - no mandate for "radical change for radical change's sake". I'm fairly confident that the slate I'm recommending might take a pretty radical route to get there but would, in the end, take care of continuity with R6 very tastefully. -t > > > Election time is here again. A couple more days and the Scheme > > community will have a set of new steer-ers. > > > I have argued at this place before that good language design needs > > a feedback loop. Language designers write down specs; language > > implementers translate those specs into compilers and interpreters; > > programmers use these implementations to produce useful software. > > The loop comes in when implementers inform designers of flaws, > > inconsistencies, mistakes, errors, and other internal consistency > > problems in the specs. This is clearly happening with R6RS, and it > > is good. Implementers are a biased bunch, however. After all, they > > work on just one kind of program, and in a highly specialized > > domain that has been mined for a long time. How can you trust them? > > [*] > > > > The loop becomes truly useful when people write large software > > systems (not just compilers, because they really are special > > cases!) and find that the language fails them in some way. Such > > failures can come in a number of flavors. For a document such as > > R6RS, we should hope that programmers can discover problems with > > porting systems that are apparently due to ambiguities, flaws, > > mistakes, roaches in the actual document (as opposed to a specific > > implementation) > > > > > The last thing we want from a steering committee is a radical > > commitment to change (whatever it may be); a prejudice concerning > > R6RS; a closed mind about the size of "Scheme" (it's too large, > > it's too small); a willingness to steer without making > > observations. A steering committee of overbearing curmudgeons is > > not what we want. > > > > What we do want is a committee that is willing to figure out how > > the listening is going to happen; how we can possibly finance a > > systematic way of listening (writing NSF grants, anyone?); how the > > feedback is best channeled into language design. > > > > Let's hope we get such a steering committee. The Scheme community > > deserves it. > > _______________________________________________ > r6rs-discuss mailing list > [email protected] > http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
