A weak standard has a rather small value. If one can not expect
support of language features beyond a small "portable subset", what's
the point of the rest of the standard? It seems it is better to have a
small well designed standard for the language core and to leave the
rest to the library (defined by another standard perhaps, or a set of
RFIs) than to have another CL-sized language with a caveat that most
of it is optional to implementors. But maybe you are arguing the same
point.
--andrew
On Feb 24, 2009, at 4:59 PM, Thomas Lord wrote:
>
> 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
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
