You point out that in this brave new world I'm describing, "balkanization" would be the expectation: we could very likely wind up with lots of Scheme code where some of that code ports among implementations A, B, and C and other parts of the code port among X, Y, and Z and its just a hopeless mess if you are trying to mix and match from among that code. That's a definite possibility. I have two responses:
First, there's a humanist response. Either we cast a bunch of people in the society around Scheme from the "community of Scheme" - or we deconstruct the standardization process and remove that authority. I say: people matter more. Second, a technical one: If you want to see a kind of "evolution" / "natural selection" that yields a reliable, widely adopted basis set of Scheme I think that the process I'm describing facilitates that outcome far, far better than the current trajectory of the Singular Report is doing. In my world, if 5 and 5 of us polarize on some issue we don't have to see which of us can overcome the other on mailing lists or in the power structure that flows from the SC. Rather, we can simply break off and each make our separate statements and let history be the judge. The economic incentives to resolve our differences remain and, where it matters, I assume we or someone would eventually do it. The brands of successful products should support the natural authority of various Scheme standards rather than having the brand Scheme support various products to the exclusion of others. -t On Tue, 2009-02-24 at 12:37 -1000, Shiro Kawai wrote: > I understand, and almost agree with you about Scheme > not needing assurance of "standard" to persuade managers > to sign the PO. I also agree that quite a few portable > issues can be resolved with more informal documents > (e.g. SRFIs). > > But I'd argue against having multiple "portable practices", > to a certain degree. > > Sure you might be able to port a Scheme application from > R3 to R4 to R5 (or even to R6) without much pain if the app > consists of one whole chunk of code, no matter how big the > chunk is. But what if the code is deeply layered? > > Suppose there are two different exception mechanism X and Y. > If you have a monolithic application that uses X and you want > to adopt Y intead, it might be relatively easy to port change that. > > Now, supports there's a huge library A that adopts X, and > another huge library B that adopts Y. A and B are both > actively maintained by large number of developers. > > You want to mix library A andFor example, Harvey's students might reams and reams of nice, clever, valuable case independent code > B in your application. But you > need to raise and catch exceptions in one way. Your choice is > to modify A to use Y, or modify B to use X; either way, it is > likely that you have to fork A or B. At best you can persuade > developers to put a conditional clause in A or B to switch > underlying exception mechanism, but it may not be welcomed, > since there are more switches can be involved---records, > object system, etc---that clutters the source. > > This is, certainly, a matter of degree. There are incompatible > libraries in other languages; I can't mix easily an widget based > on GTk and another based on Qt (I can, but ugly). C++ templates > had similar issues before STL emerged, IIRC. > > I kind of count on natural selection, and want to see multiple > standards to compete each other to make them better. But at some > level I'd like to have stable basis on which I can build large > chunk of code without worrying much about the basis will fade > away. The question will be where to draw a line. I don't > like R6RS, but I understand why they include these stuff in > order to allow portable librarlies to be written. What I wish > was about process---even eventually we'll have one exception > system, one record API and one I/O API, could it possible that > we try multiple SRFIs and multiple implementations and see which > one wins over time? > > --shiro > > > From: Thomas Lord <[email protected]> > Subject: [r6rs-discuss] what is a standard? > Date: Tue, 24 Feb 2009 13:59:29 -0800 > > > > > 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
