Re: [Scheme-reports] *TELUS Detected Spam*Re: [r6rs-discuss] returning back to pattern matching

[Vincent Manis <vmanis@x>]

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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports