OK, here's my $0.02 worth (it's Canadian funds, so less than 2 cents in the US or the Eurozone :)
1. The division into large and small is a VERY good idea. I agree with Elf that (or (equal? large-language industrial-language) (equal? small- language teaching-language)) => #f, so I guess I'd like to see different terminology, though I'm not sure what it might be. 2. This probably marks the retirement of the term `Scheme' to mean a specific programming language, just as `Lisp' was retired long ago. For the small language, I propose `Notion', which, according to Wiktionary, is a `general or universal conception', or a `sentiment or opinion', or an `ingenious device'. In Canada, at least, a department store had/has a `Notions Department', which sells yarn, thread, and similar products. I have no opinion on the name of the large language. `Notional Scheme' and `Full Scheme' might work, as well. I would NOT support `Common Scheme' :-). 3. In order to reduce the number of documents that claim to define the standard, I hope that the large language core document (as opposed to any library documents) will contain---rather than refer to---the small language core document. (This need not introduce any version skew.) 4. I'd be opposed to having the large language document describe a set of libraries that in some way are optional. If there are libraries that implementers disagree on, then those are by definition outside the scope of the core language. To this end, I hope the Working Group circulates its list of projected libraries early, so as to reach some kind of consensus early. An implementation ought not to be able to call itself compliant with R7RS-Large unless it has passed some kind of conformance test. The one area where this causes me discomfort is bignums. However, the Chicken solution, having an external extension that supports the full tower, seems very attractive as a way of complying with this requirement. 5. I'm neutral on the subject of standardizing FFI. On the one hand, the benefits of a portable standard are obvious (both for portability across implementations and for practical SWIG support); on the other, it could paralyze the Working Group. If there is sentiment that FFI should be standardized, I propose that a subcommittee be struck to hammer out a standard, presumably somewhat similar to the Haskell FFI. If the subcommittee fails to reach consensus, that need not derail the specification effort. (This FFI need not prohibit an implementation from providing alternate foreign function facilities, e.g., embedded C code.) 6. I hope the Working Group considers including some sort of CLOS-like facility in the large language. This would allow a clean unification of records and conditions, and thus would help the large language comply with the first sentence of the Introduction to the Scheme reports. 7. I'd like to see a non-normative addendum that discusses proper practice in library design, in particular how to ensure that a library can be used by multiple Scheme systems where that's possible. (Because it would refer to files, directories, and environment variables, it does not properly belong in the specification.) I'm very happy with the direction the Steering Committee has taken, and look forward to their next steps. --v _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
