On 2009-09-05, at 18:38, Aaron W. Hsu wrote:
On the other hand, I agree that's it is a big pain to say, "We are Scheme + Extensions N through X ...," and I don't think we should do this. Instead, Meta or Collective standards should define a set of the primary standards which comprise an useful set of functionality that Scheme's will want to use. So, one meta standard might be a graphics or gaming collection, useful for writing graphical programs. This might include an FFI, OpenGL, and lots of floating point math.
I think there's a middle path here, and this extract from Aaron's message hits it pretty well. Let's make Core Scheme and Ultra Scheme (I worked in a branding-obsessed company for seven years) be standards with no options. Either an implementation complies with one of these standards, or it doesn't (such standards will have language in them about not specifying such things as the maximum size of program that can be executed or the maximum numeric values that can be processed). Wherever there's sentiment for providing an option, the corresponding WG should not include any language at all on that particular subject. At the end, as well as the language reports, the Steering Committee can publish a list of said `options' as an starting point for future standardization. Implementers and users can then develop future standards, e.g., `R7RS FFI for C-based Systems', or `R7RS OpenGL Bindings' which can then be published under the aegis of the committee, on their own schedules (I would insist that such add-ons use the same format and typography as R7RS itself, but maybe that's just because I love the ALGOL 60 Report so much :). I'm not sure if I like the term `meta' or `collective' standard; to me, they're just add- ons. But Aaron's point is really well-taken.
This sounds like the SRFI process, but there's an important difference. R7RS should be normative, rather than descriptive. The idea is that a user can select an implementation BECAUSE it complies with R7RS Ultra Scheme and the R7RS Socket Layer, and expect a certain set of functionality. In many cases, one of these add-on standards will simply be a restatement of a SRFI; however, adoption as an R7RS standard would require some kind of ratification vote, making it in some sense official.
And if the community doesn't want to bother with these add-ons, well, we're no worse than we are now.
So, here's asking the Committee not to solve problems by including both solutions. Pick your solution, and present it for ratification. Or say that that piece of the puzzle is outside the language standards, but might be part of a future standard.
-- v
_______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
