[r6rs-discuss] Proposed features for small Scheme, part 1: a stake in the ground

[Vincent Manis]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20090905/23359496/attachment-0001.htm