[r6rs-discuss] [ANN] scheme-reports.org

[Vincent Manis]

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