On May 9, 2007, at 12:00 PM, J. A. "Biep" Durieux wrote: > Let Scheme remain the language that either does the right thing or > defers a final decision.
Since I used to think along the same lines, I would like to respond to this line. I am not an editor, I am not involved with the process, and I am not trying to influence any decisions. Short: Pascal's answer is spiritually close to what I think. Long: My own journey may suggest why this purist view is plain wrong. First insight: Scheme is _not_ a programming language. The reports define a family of somewhat related languages. If you stick to the syntax blessed by the report, you could imagine that one program may produce the same behavior in all implementations. This is not true and not intended. The people who wrote the reports on 3-5 had/have latitude for the compiler writer in mind and, as a result, you get - at a minimum - differing error behavior (not counting the error messages). For some programs, you may also get differing positive behavior. Since there is no algorithm to decide whether your parenthesized 'thing' (intentionally chosen word) is a program, you may not be able to decide which behavior is correct. Second insight: There is no such thing as "the right thing." Programming languages are media for expressing computations for people (and computers). [This is almost a quote from SICP, which people may just buy nowadays.] As such they come with an context (syntax, libraries, environments) that form the Human-Language Interface. We -- as a community -- should coin and use the phrase HLI for this. If you accept this part, you see that people are involved. When people are involved, you need compromises. What's intuitive and right for one isn't for someone else. What's intuitive at first glance, won't be after a couple of years of experimentation. If you don't accept the part, you can still argue that computational models are all equivalent according to the Church-Turing conjecture and really there is little that computational theory can give you. My own attempt at separating them via an Expressiveness theory does NOT conflict with this statement either. (True for both the syntactic as well as the semantic version.) This theory just works out the trade-offs even if you differentiate computational frameworks via restrictions on the translations. Third insight: In light of the first two, the Scheme report can either play the role of a marketing and branding tool (3-5) or help us eliminate some differences between implementation (i.e., making portability somewhat easier than it is now). For the longest time, RnRS was just something you cited in academic papers and descriptions of your implementation to place everything into an easily classifiable context for readers. That's called marketing. In light of the second insight, people who implemented real, large Scheme systems but not compilers (say programs such as DrScheme or SirMail or extensible web servers) and were implementors adjusted their language for working on large systems that interact with the existing real world for computers. This often meant writing macros but in turn, making macro systems powerful and real. Now the various members of the Scheme family of languages are far apart. We can either compromise and get things to grow together in the sense of portability, the best operational measure of "togetherness" or we can give up and just write another marketing tool with little meaning for the various extensions. I have the sense that the majority of the editors chose a route close to the "growing together part" and I applaud them for that. -- Matthias _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
