John Cowan wrote: > David Van Horn scripsit: > >> As an exercise in trying to figure out precisely what one can expect to >> find when moving between Schemes, I reviewed the R3,4,5,6RS and >> IEEE/ANSI standards. I wanted to find their least common denominator >> (the "essential" Scheme); a list of must-haves for a Scheme to be a Scheme. > > R2 and R3 are dead. R4 is very nearly dead; the implementations that only > support R4RS are pretty much unmaintained. R5 and R6 are where it's at.
If you consider R5RS to be a compatible extension of R4RS (which I do), then R4RS is the most widely supported Scheme standard. If you consider R4RS to be a compatible extension of R3RS (which I do), then R3RS is the most widely supported Scheme standard. And what about IEEE/ANSI Scheme? You left that off. It is the most mature and long standing Scheme standard (and is more or less R4RS). It was approved in 1990 and reaffirmed in 2008. The small language has to be supported by 90%(!) of the electorate. That is a nearly unreasonable level of agreement of what should be in Scheme. I think we should start with something very well established (I think IEEE Scheme fits the bill) and very conservatively add the features and requirements that make extending that language to the level of R6RS possible. Just to be clear: I want a R6RS-like language. I do not want to program in R3RS Scheme. > 84 bound symbols. My question is, why do we need a standard as tiny as > this, when tiny R5RS-compliant systems that are perfectly practicable > for the purposes mentioned above, like chibi-scheme, already exist? > (Version 0.2 has 4308 lines of C and 708 lines of Scheme, plus 578 lines > of Scheme in tests.) Counting bound identifiers in a language with macros and modules (which are required by the working group charter) is not meaningful. I never said we need a standard as tiny as this. I was just trying to outline what it means to be "Scheme". I think it is reasonable to say any system not supporting that subset is not a Scheme. This is a useful reference point in a standardization discussion. I do think if you take this language, add syntax-rules macros and the R6RS library system specialized for this sublanguage (which will be quite simple), and figure out how semantic and lexical extension are going to be allowed for, you have something which might be able to garner 90% support while still allowing the consistent and compatible extension of that language to an R6RS-like standard. David _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
