I think we are hitting on some essence of the social problem, here.
It is hard to say, exactly, what R1..5RS represent. We can't certainly
say they represent any one thing. Yet, we can say a little bit, with
some confidence:
When Scheme was first announced, prior even to R1, there was
some popular perception that something fundamental had occurred.
The foundations of programming languages in theory, as then understood,
resonated with then-practical implementation techniques in an
unprecedented way. For example, the essence of control could be
modeled abstractly as continuations but, here, was a practical compilation
technology that more or less directly reified that model. The tantalizing,
never-quite-realized speculation of the Rabbit thesis was that, later,
data structure realization would "fall out" as a small matter of optimizing
the automated optimization of environment representations just as
easily as a compiler could be spared the need for any special cases
to handle loops, AND, or OR. The spareness -- the reductionism --
the aspiration of boiling the essence of programming languages in general
to a small kernel of truly foundational concepts -- characterizes R1..5.
Even if the hope, there, can never be a reality -- that is the spirit of
of the earlier revisions. That is what they represent. They report on
a line of thinking in pursuit of that hope.
What, then, if that hope is widely perceived as lost? A need for
practical compromises and forging ahead with arbitrary choices in
face of presently undecidable questions has community value?
By all means! Forge ahead! We have SRFI as an example of new
processes for organizing around documents -- and while SRFI isn't
quite right for a language standard of commercial and academic
significance, slight tweaks on the process might be.
But, by no means: why usurp R6 for all of this? Why change
the spirit of the report series in such drastic ways? It seems
violence against the community. It seems the usurption of a
brand-name that has already achieved its good place in history.
It seems a fundamentally economic power grab where, formerly,
the Rn series enjoyed a far more innocent place.
The R6 draft is discontinuous with its ancestors in almost every
significant way except for the names of the editors and steering
committee. Perspective on semantics? Tossed overboard.
Minimalism? Displaced by a rather artificial spill-over into
"standard libraries". Arbitrariness? Well, have you seen the
state of Unicode support?
Matthias, you are right in this: the R6 draft aims to completely
change the *role* of the report series in economic reality.
Why bother? Is the R_ brand-name of such high value?
Could not the effort have been mounted under another name?
Boycott the R6 ratification process. Better that R5 might be
the last ever in the series. We might like the implementations
and standard that several editors cojoin to create -- but there's
no good reason to call it Scheme.
-t
Matthias Felleisen wrote:
> 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
> r6rs-discuss at lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
>
Received on Wed May 09 2007 - 19:37:39 UTC