Has anyone else noticed what a big deal
we make, in the society that surrounds Scheme,
about the "completeness" of implementations?
It is as if the Report's main function is
to hand out a homework assignment to implementers
who then get an "A" for checking off all the
items on a list, a "B" if they only miss a few,
etc.
I guess the intuition there is that the Report
strives to define "The Portable Subset of Scheme".
Let me add some emphasis. We treat the Report
as if its purpose is to define "***THE*** Portable
Subset of Scheme."
So much do we make a fetish of that definite
article ("***THE***") that we are willing to
ostracize people and implementations which take
a dissenting line. It is as if the society is
afraid that if we take away that "***THE***",
Scheme will cease to exist; dissolve in a sea of
chaos; simply Lose the historic battle among
programming languages.
In the rest of the world, in regards to other
programming languages, we define "***THE***"
standard for a language for a simple economic
reason:
The function of such standards is to lower the
price of implementer labor at the cost of
creativity and innovation.
A budget manager for a programming project can
look at his yearly expenses for a C compiler
license and/or support. A snapping young
saleswoman from a competing compiler firm can
knock one day and say "Hey, I have a substitute.
Costs half as much, works just as well."
It doesn't matter to the budget manager that the
C language, thereby, stagnates. It doesn't matter
that C compiler implementers are strongly economically
discouraged from innovating at the language design
level. The main thing is to keep costs down.
So it was, too, with Common Lisp. The customers of
of the lisp vendors demanded CLtL after one too many
of them got burned spending 4 months instead of 1 month
moving code from one system to another. Those customers
were suspicious of an emerging pattern of "lock-in".
The implementers agreed among themselves that their
businesses would indeed do better - the market be larger
than otherwise - if a simple "commodity lisp" were
defined and, thus, we got CLtL.
Now, to my eyes - Scheme is not much like this.
We do indeed have a very, very small number of
what could be described "commodity implementations"
and, yet, the commercial market for those appears
quite small and customers there do not appear overly
agitated about lock-in and the need to make a commodity
of Scheme.
Rather, time and time again progress comes because
an implementer goes off and innovates - and not always
with that much care for the standard.
So is the society around Scheme and the "Scheme community"
deluding itself? What's our goal in trying to
declare ***THE*** standard?
Perhaps one thought behind the likes of R6 is
the hypothesis that there must exist some nice little
core which, once set down, allows all subsequent innovation
to be pushed off to libraries or to new core types
and procedures. If there are people who believe that
(rather than merely act as if they believe it) I think the
burden of proof is on them: I don't believe such a core can
exist.
Perhaps another thought behind the likes of R6 is a
kind of "if you build it they will come mentality."
You know, if we have a Scheme standard that is just
as robust (or more) and better than, say, the standard
for C or than CLtL: suddenly we'll all find jobs and
riches. Again, the burden of proof lies with those
who believe it: to me, that looks like "cargo cult"
thinking.
I think that we need to deconstruct the whole notion
of a standard and come up with something better.
In the days around R3 and R4 I remember having occasion
to use more than one implementation of Scheme and having
to port both my own and other people's code around between
implementations. I didn't do so a huge amount but I did
enough. It was never a trivial, effortless process - nor
was it ever very hard.
I remember at one point - just for fun - reaching back
and porting *even Guy Steele's Rabbit Compiler*. Even
that exercise, for which the whole Report-as-standard
concept was irrelevant - didn't take long. (I can
report that the Rabbit compiler was messy in places,
slow, and buggy. :-)
So, in that spirit - I don't think I need some document
telling some made-up, idealized "core" which "defines"
what Scheme is.
It's nice to have a few words for reference that talk
about values in general. It'd be nice to have a
document talking about, say, cons-pairs in general.
Another about some general aspects of lambda and then
several others about various kinds of extensions
or variations people make.
And, yes, it would be good to have a document describing
"best portable practices" (updated periodically) or
"best compilable practices" (reporting on the state of
what compilers these days are doing).
There is no reason, even, to centralize anything other
than book-keeping authority. Are there 5 contradictory
descriptions of cons cells? Why not? Three different
portability guides, each offering different advice?
So what? Why make a fetish of "***THE***" definite
article?
Subsets of the society around Scheme might want to
further define dialects. For example, a group of
compiler writers might gather among themselves to
define a dialect which each of their products compiles.
We would not say "That is ***THE*** definition of Scheme"
we would say "That is the definition of a Scheme language
which each of those compilers compiles."
An outsider might look at the resulting mess of documents
and say "Ok, that's fine - but how is the language defined?
Where is Scheme defined?"
We could all agree to say, to such an outsider: "It's all
in your head."
-t
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
