On 2010-12-23, at 12:34, Brian Harvey wrote:

>> a small set of extremely powerful features.
> 
> Amen!

Also amen. I frankly don't care if there's a loop macro in CL-Scheme, er, WG-2 
Scheme. Put it in a library named (r7rs loop), and those people who want it can 
use it, and those people who don't want it---like me---can ignore it. 
(Actually, I guess I *do* care: documenting it makes the Report bigger.) For 
that matter, WG-2 should mostly be a set of libraries that run in any WG-1 
Scheme system, though I don't particularly mind if there's a *small* set of 
extensions to WG-1 in the WG-2 core. 

As for some hypothetical case-bind form, since that can be easily created via 
define-syntax, it seems appropriate to propose such a thing via a SRFI, and 
then, if it achieves wide usage, consider it for a future Scheme standard. 

The recent discussion on Posix, UTC, and TAI dates terrified me. Indeed there 
are important issues here, and indeed there are programs that are tremendously 
sensitive to those issues. But when we start saying that a Scheme 
implementation must be accompanied by a table of leap-seconds, my head begins 
to explode, even if later on it's decided not to require this. There's a real 
danger in prescribing a language with such complicated libraries that nobody 
can implement it. Further, if the underlying OS changes, suddenly impedance 
mismatches start occurring between the language and the OS. (I remember that 
one release of UNIX had a kernel variable called nixonflg, which was there to 
account for the double daylight-saving time required during the 1973 oil 
embargo.)

As a cautionary example of this, some 40 years ago I was a graduate student 
working on a compiler for ALGOL 68. ALGOL 68 actually was a splendid language 
in many ways (two-level grammars were not one of those ways), but the designers 
had included some rather poorly-thought-out OS features. One of these was 
Dijkstra's PAR BEGIN...END construct, for concurrency. Very nice, but this was 
before threads, so nobody quite knew how it was supposed to be implemented; 
also, there was nothing more than semaphores for synchronization. Another 
feature was the design of the `transput' (I/O) system, which modelled a file as 
a 3-dimensional array of characters (pages of lines of characters). It was very 
well thought out, and quite elegant. Unfortunately, this was just before the 
invention of UNIX and the consequent gradual disappearance of fixed-length 
record formats. 

Unicode is another example. Full Unicode support requires an internal copy of 
most or all of the Unicode Character Database, which, for many applications 
that just need to throw around a few accented characters or math symbols, is 
overkill. R6RS requires a relatively small subset of Unicode, just enough to 
determine character classification. Even in a Unicode-compliant implementation, 
the number of users who need the whole megillah is quite small. A supplementary 
library that wraps the ICU library would be quite suitable for them. 

So, please: 

  1. small, clean, core language, with a modest number of extensions to 
existing standards (though, I hope, nothing that is an extension to existing 
practice). 

  2. a core set of libraries that solves, in a reasonable way, problems that 
most Scheme programmers are likely to encounter frequently.

  3. supplementary libraries, outside the Report, that add additional 
functionality, or sometimes reimplement features from the Report in a more 
general or more precise way. These start appearing once there's a body of R7RS 
users who want them, and maybe the Steering Committee might one day establish a 
WG to produce a Report on a common set of these libraries. 

I am very optimistic that the current process will lead to these objectives 
being satisfied, but still want to encourage the participants to focus on 
creating a language that will sharply increase the willingness of programmers, 
educators, and others to adopt Scheme. That's what really matters. 

-- vincent
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

Reply via email to