[r6rs-discuss] steering Scheme

[Thomas Lord]

On Wed, 2009-02-18 at 11:05 -0500, Matthias Felleisen wrote:
> On Feb 18, 2009, at 3:04 AM, r6rs-discuss-request at lists.r6rs.org wrote:
> 
> > Message: 11
> > Date: Wed, 18 Feb 2009 00:04:00 -0800
> > From: Thomas Lord <lord at emf.net>
> 
> 
> 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
> r6rs-discuss at lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss