The R6RS editors would like to make three announcements:
1. Shortly after we began our work, we created a mailing list for our discussions and agreed that the mailing list archive should be made public at some point after the R6RS was published. During our September 12, 2006 meeting, we voted to make the archive public immediately. It has taken us a while to get around to it, but the archive is now available at http://www.r6rs.org/r6rs-editors/.
2. During our October 19, 2006 meeting, we committed to providing a formal response by December 15, 2006 to all formal comments submitted by November 15, 2006. The timing of our formal responses to formal comments submitted after that date will be decided at a later time. For more information on the formal review process, see http://www.r6rs.org/process.html.
3. Also during our October 19th meeting, we committed to producing a new draft of the R6RS by January 15, 2007, which will take into account comments and suggestions made by November 15, 2006. LaTeX source code will also be provided for the drafts.
We appreciate the response to date from members of the Scheme community.
> > We appreciate the response to date from members of the Scheme > > community.
> There were few comments on this group so far. I wonder what the > opinion of the community and especially the implementors is. > Benedikt
Well, I for one am impressed by their caliber. I am interested in these archives and will slowly be digging into them, looking for reasons for particular decisions, discussion of tradeoffs, etc.
-- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYbl...@STRIPCAPStelus.net The Rhythm has my soul.
> > We appreciate the response to date from members of the Scheme > > community.
> There were few comments on this group so far. I wonder what the > opinion of the community and especially the implementors is.
A desaster, that's what the current R6RS draft is. It breaks with fundamental ideas of Scheme by introducing bloat and redundancy. Traditional niches where Scheme is used as an embedded scripting language (or as a minimalistic language for embedded systems) are abandoned by making the full numeric language tower mandatory and requiring full unicode support. Adding the politically correct macro- and module system was somehow to be expected, though. R6RS completely disregards de-facto standards like SRFI-1, yet looks like a device to push one particular persons' pet-SRFIs... Further brain-damage like hardcoding UNIXisms, specifying the unspecified and introducing the hilarious ASSP makes it complete.
bunny...@yoho-gmail.com wrote: > A desaster, that's what the current R6RS draft is. It breaks with > fundamental ideas of Scheme by introducing bloat and redundancy.
Criticisms of the draft R6RS are welcome. I hope you will participate in the ongoing informal discussion or by making making formal comments. See http://www.r6rs.org/
> Traditional niches where Scheme is used as an embedded > scripting language (or as a minimalistic language for embedded > systems) are abandoned by making the full numeric language tower > mandatory and requiring full unicode support.
The draft R6RS proposes portable mechanisms that would allow embedded programs to exclude Unicode support and to specify certain subsets of the numeric tower, e.g. fixnums only or fixnums and flonums only. For embedded systems, this would represent a distinct improvement over the R5RS.
Support for embedded systems could be improved further. Improvements to the draft R6RS will become more likely if those who understand the issues take part in the discussion.
bunny...@yoho-gmail.com wrote: > A desaster, that's what the current R6RS draft is. It breaks with > fundamental ideas of Scheme by introducing bloat and redundancy. > Traditional niches where Scheme is used as an embedded > scripting language (or as a minimalistic language for embedded > systems) are abandoned by making the full numeric language tower > mandatory and requiring full unicode support.
Well, I agree and then don't agree. Scheme was intended to be as much as possible complete without putting a heavy burden on implementation details and numerics. I agree, that numeric tower is needed, hygienic macros etc. are needed. As a matter of fact I accept all new proven ideas which may extend Scheme language expressiveness without expanding the language if there is possibility to put matters simply to macros or libraries. The line is thin: if we cross it we could forget Scheme and move to ML (and it's inkarnations).
> The draft R6RS proposes portable mechanisms that would allow > embedded programs to exclude Unicode support and to specify > certain subsets of the numeric tower, e.g. fixnums only or > fixnums and flonums only. For embedded systems, this would > represent a distinct improvement over the R5RS.
R6RS pretty clearly states:
"Implementations are required to implement the whole tower of subtypes..."
and
"Implementations are required to support exact integers and exact rationals of practically unlimited size and precision."
Thus, to be R6RS compliant, and implementation could not restrict itself to supporting only a subset of the numerical types.
bunny...@yoho-gmail.com wrote: > William D Clinger schrieb:
>> The draft R6RS proposes portable mechanisms that would allow >> embedded programs to exclude Unicode support and to specify >> certain subsets of the numeric tower, e.g. fixnums only or >> fixnums and flonums only. For embedded systems, this would >> represent a distinct improvement over the R5RS.
> R6RS pretty clearly states:
> "Implementations are required to implement the whole tower of > subtypes..."
> and
> "Implementations are required to support exact integers and > exact rationals of practically unlimited size and precision."
> Thus, to be R6RS compliant, and implementation could not > restrict itself to supporting only a subset of the numerical > types.
I fail to see why this would prohibit an implementation from excluding those features from a program.
> > Thus, to be R6RS compliant, and implementation could not > > restrict itself to supporting only a subset of the numerical > > types.
> I fail to see why this would prohibit an implementation from excluding > those features from a program.
That's not the point (even though I have trouble understanding what you mean by "excluding features from a program"). The point is that it is impossible to be R6RS compliant (for an implementation) without providing support for all number types (or complete UNICODE case-conversion, for that matter).
bunny...@yoho-gmail.com wrote: > Thus, to be R6RS compliant, and implementation could not > restrict itself to supporting only a subset of the numerical > types.
That is true, but an implementation that is intended primarily for embedded computing, and which intends to provide efficient support only for fixnums, or only for fixnums and flonums, can still satisfy the requirements of the R6RS by using the reference implementation of the tower, with no attempt to optimize any part of it.
That takes approximately zero effort.
There are far more serious problems with the R6RS, even for embedded systems, even for the arithmetic that would be used in embedded systems. For example, those who care about embedded computing would do well to design suitable subsets of the (r6rs) library for that class of applications, and to propose those subsets as standard libraries. While it is true that the R6RS provides facilities that individual programs could use to implement those libraries themselves, standardization would promote portability and make it easier for systems to link together only the code that is needed.
We should discuss the real problems, not the illusory ones.
