On Tue, 21 Aug 2007, Thomas Lord wrote: <snip> > Those of us who aren't entirely excited about 5.97 have solid > criticisms all around, in my view, but we now "owe the > community" (so to speak) some work to back up our criticisms > with a pragmatic alternative. >
fair enough. pragmatic alternative to r5.97, based on the 'guiding principles' section of the 1 mar 2006 r6rs status report: * allow programmers to create and distribute substantial programs and libraries eg SRFI implementations, that run without modification in a variety of Scheme implementations; clearly, we need some form of module/library system and some means of publishing what modules are available. we already have SRFIs 0, 7, and 55; additionally, most implementations have some form of module system. what would be the functionality intersection of the SRFIs and assorted module systems? furthermore, in the interests of interoperability, would it be possible for each implementation to publish its differences from the standard as a module (or library) that could be included with a module system (ie, if i am running chicken, an ideal module system would allow me to add a 'guile' module for whatever functionality guile has outside of r6rs, etc)? this may require some meta-FFI semantics for expressing scheme to outside languages. there are also some clear pitfalls here between interpreters and compilers that need to be explored. * support procedural, syntactic, and data abstraction more fully by allowing programs to define hygiene-bending and hygeine-breaking syntactic abstractions and new unique datatypes along with procedures and hygenic macros in any scope; define-macro would be a plus. syntax-case would be a plus (potentially). new datatypes... record semantics would mean a cleanup of SRFI 9 and 57, not an entire rewrite, in my opinion. * allow programmers to rely on a level of automatic run-time type and bounds checking sufficient to ensure type safety while also providing a standard way to declare whether such checks are desired; first, this seems like fluff and unnecessary to include. second, i do not recall anything in the r6rs draft that addressed this. this amounts to simple correctness checking if i understand properly. * allow implementations to generate efficient code, without requiring programmers to use implementation-specific operators or declarations. again, i believe that this requirement is in error. what constitutes 'efficient' code is dependent on the system's intended use. a number-crunching app doesn't necessarily care about string handling. additionally, a one-size-fits-all 'efficiency' definition destroys the usefulness of individual implementations. * In general, R^6RS should include building blocks that allow a wide variety of libraries to be written, R5RS already allows this. *ANY* real language allows this. * include commonly used user-level features features to enhance portability and readability of library and application code, and exclude features that are less commonly used and easily implemented in separate libraries. who or what has determined what are 'commonly used user-level features'? almost all of the changes in r6rs are not things i commonly use nor intend to. and how did unicode support become both commonly used and not easily implemented as a separate library? ditto the arithmetic? ditto most of the changes? * R^6RS Scheme should also be backward compatible with programs written in R^5RS Scheme to the extent possible without compromising the above principles and future viability of the language. 'backward compatability' and 'future viability' were both obviously discarded. * With respect to future viability, we operate under the assumption that many more Scheme programs will be written in the future than exist in the present, so the future programs are those with which we must be most concerned. given the vocal and reasoned opposition to r5.97, is this a valid assumption? i for one can state that i will not be writing r5.97 scheme programs. period. many/most implementators have stated that they will not support r6rs. how exactly is this new proposed standard increasing the viability of the language? please, people, if the point of r6rs was to allow the language to be viable commercially, to allow code to be more-or-less implementation independent, and to remain true to scheme... scrap the proposed draft. find some module or library system similar to all existing ones, and give it sufficient power to allow implementations to export their differences as modules includable by others. "Programming languages should not be designed by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. *Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.*" Don't forget this. -elf _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
