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 and 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
