On Sat, 05 Sep 2009 01:40:07 -0400, Vincent Manis <[email protected]> wrote:
> I really hope we don't go down this path; if implementation A implements
> features
> x, y, and z, while implementation B implements features u, v, and w, you
> end up
> with essentially no portability. Cobol did that, with its subsets, and
> the
> results weren't very good: vendors ended up implementing a common core
> of subsets,
> and the ones that only a few (or no) implementations provided merely
> ended up
> vanishing from the language.
[...]
> But if an implementation claims to implement R7RS Super-Dooper Scheme,
> that
> should be a full implementation, not merely the set of features the
> implementer
> felt like providing.
The reason I suggest doing something like this is to cater to as wide a
possible audience for standardization, to help standardization move along,
and to make it possible for specialized Scheme products to clearly adhere
to some set of features which may need to be severely or very specifically
aligned/restricted. In practice, most general-purpose Schemes are going to
implement many, if not most of the standards, because they're useful and
users will want them.
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.
The benefit of meta standards is that you can leave all the regular work
to other groups and focus purely on the issue of addition or removal. They
can also add and remove as needed, and not slow themselves on design
issues, which take more time.
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
