Lambda the Ultimate

And no matter one's take on Scheme in general or R6RS in particular, the Scheme community is ripe for studying the forces that shape the evolution of PLs.

Short of anything else, there ought to be something in all this that can be used for your CUFP presentation on impediments to adoption of FP. :-)

My view is that the majority of people against R6RS are not interested in increasing the adoption of Scheme. There is plenty of work on changing culture, and I could talk about some of this, but given the short duration of the talk I'll probably concentrate on suggestions for those interested in increasing adoption. It is also likely to generate less flaming.

I'm not sure you are right that most dissenters don't care about wider adoption. Some feel just as you say and I hope he won't mind if I point to Brian Harvey (one of the designers of introductory CS curriculum at UCB) is a good example. I think Harvey made a good case for dissent from that perspective.

However, some of the objections weren't about whether to create portable features that might increase adoption but rather how to create those new features. The choice that stood before the Steering Committee and the Editors when this started was a choice between self-nominating to write a new revision to the famous report, or to do their work via the more egalitarian SRFI process. Using the SRFI process (in cse you aren't familiar with it) would have allowed the formal, community-reviewed publication of the same document under a different, non-rival title.

I think that the bulk of the controversy here is fundamentally economic and is about the the economic value of the title "R^xRS". Whoever controls that title controls the most widely accepted definition of "Scheme". People use that title or the word "Scheme" in textbooks, on resumes, on CV, in academic papers, in advertising, etc. R6RS has huge economic impact if we confine our attention to those areas -- absolutely huge, touching nearly every member of the community.

Prior to the process reboot that led to R6, that title, the definition, was up in the air. Nobody clearly owned it. This group laid a claim and invoked squatters rights.

That's not a flame (I did vote "yes," by the way). It's just an observation of the issues here and how it is about more than the question of "increasing the adoption of Scheme."

No, it's about the definition of Scheme, in the Humpty Dumpty sense (per Lewis Carroll). The main virtues of the present R6 are that hopefully it will lead to a few libraries and, hopefully, it will not be all that hard to overcome and replace.

-t

I find myself strongly inclined to side with the "no" camp and the concerns about the report doubling in size, the apparent push to include features that can (and have) been implemented outside the core language, and the concerns that seem aimed at making Scheme more static, at some significant potential cost to both its ease of implementation (well, apart from call/cc...) and "fire it up and try it" nature. I guess, at the end of the day, I fail to understand what was wrong with R5RS and the SRFI process. Library concerns seemed to me to be adequately addressed by SLIB. R5RS has excellent implementations for development as well as excellent implementations generating native code.

So count me among the ones who wonder what problem R6RS is intended to solve and who seriously question whether R6RS adheres to the goals articulated in the report since Will Clinger wrote it.

the concerns about the report doubling in size

This is a meaningless metric [Edit: in isolation]. The report would be significantly smaller if things like Unicode and type-specific arithmetic were removed. A report describing pure untyped lambda calculus would be even shorter. What's the real goal here?

the concerns that seem aimed at making Scheme more static

For example? R5RS defined a significantly static language, and R6RS has primarily made that harder to ignore[*], not fundamentally changed it. However, many people coming from other Lisps seemed not to have noticed Scheme's differences in this respect, perhaps encouraged by a couple of popular interpreters, and this has led to confusion on this subject.

I fail to understand what was wrong with R5RS and the SRFI process.

You would probably understand this better if you tried to write Scheme code that is intended to run on multiple implementations. Aside from SLIB, which is essentially its own standard (and not universally loved outside of the context of the SCM interpreter), how many portable Scheme libraries can you name? Note that SRFI reference implementations are often significantly unportable. One of the more successful portable libraries is Oleg's SXML, but Oleg has bemoaned the problems with making that library portable. And all SXML has to do is process lists, i.e. it doesn't make any particularly onerous demands on a Scheme implementation.

R5RS has excellent implementations

Yes, it does, but you can't easily write programs that run on more than one of them.


___
[*] Edit: this doesn't necessarily prevent the implementation of dynamic constructs.

You would probably understand this better if you tried to write Scheme code that is intended to run on multiple implementations.

How many implementations plan to implement R6RS?

Certainly enough to make it useful. The four represented by editors and former editors will implement it: Chez, Larceny, PLT, and Scheme 48. A few other implementors have said they would implement it. If the resulting compatible implementations do succeed in improving the availability of portable libraries and other code, there will be a strong incentive for other implementations to support it.

I have to agree that if, e.g. we get some unified successor to Planet and Snow, it will have been worth it (not that it isn't worth it if that doesn't happen; I'm content to let the Scheme community decide that). Despite your good points made in your earlier reply, I remain deeply skeptical about R6RS, but that is indeed likely to be based on my appreciation of R5RS Scheme for essentially pedagogical purposes—making writing "portable," "real-world" Scheme possible/easier hasn't been a priority for me, and in fact greatly motivated my leaving Scheme behind in the first place.

... the scheme community needed to sort out its common ground on macros, library systems and the relationship between them. It is hard to imagine a more painfree mechanism for tackling this that had a decent prospect of reaching its goal.

Furthermore, let's not pretend R5RS was perfect: it had some important and hard to tolerate incompatibilities with the Unicode way in its handling of characters and strings. There's more in the way of `issues' with R6RS than R5RS, but it's really needed by people in the community.

the concerns about the report doubling in size

This is a meaningless metric [Edit: in isolation].

A large increase in size means a significant opportunity for minor errors (and major ones, for that matter, but that is not my concern here). I understand that you and the other editors have worked extremely hard to produce a high-quality standard, but the continuing trickle of minor errors being reported to the r6rs-discuss mailing lists suggests that the R6RS will be published with many remaining minor errors. Now, no language standard is perfect, but I think this will be a significant difference from the R4RS and R5RS, which were published with very few minor errors.

Matthew Flatt's R6RS voter registration statement made some excellent points in this respect. I'm tempted to quote bits of it here, but I think it's better to read the whole thing (just four paragraphs).

To Matthew's statement, I would add that a decision seems to have been made early on that R6RS was to be quite ambitious. Some of the history of this can be seen in the early editors' progress reports at schemers.org. The first progress report (before I became an editor) excludes a few major features from consideration, such as support for processes or threads, networking, and OO. However, many other features were on the table, including the module system, macro system, records, Unicode, and exception handling, all of which were listed as "controversial or difficult but necessary".

The judgement that these things were "necessary" made it inevitable that R6RS would represent a far larger jump from previous reports than had previously been the case. This in turn made it inevitable that R6RS would contain more errors than previous reports. We need to figure out a way to deal with that, but extending the period of pure specification-writing would not have been sufficient.

[...] the concerns that seem aimed at making Scheme more static, at some significant potential cost to both its ease of implementation (well, apart from call/cc...) and "fire it up and try it" nature.

What exactly do you mean "static" in this context? Is it as in "static vs. dynamic," or just "static vs. open to change"?

My take (as somebody who's used Scheme professionally... well, ok, Kawa, which has some departures, but still, close enough to make me interested in this process) is that some of the more "dynamic" things in Scheme, like the top-level environments and eval, are things that (a) you don't want to use most of the time for your finaly running program, (b) have never been defined very clearly at all (where in R5RS does it say that the set of bindings in the top-level environment can change?).

My take, frankly, is that all this stuff should be defined clearly so that static and dynamic environments can be both supported, and both used for eval. For example, as part of an effort to provide a fast implementation of a query language, I want to be able to write code that uses eval at runtime to compile a dynamically constructed lambda expression, and have the compiled version be just like a statically compiled one, with all dependencies on top-level bindings resolved right away, without using an intermediate lookup in a dynamic binding environment (as used by a REPL that supports interactive introduction of new bindings in the top-level environment). How do I do that in a portable fashion?

Library concerns seemed to me to be adequately addressed by SLIB.

So, what's a good specification for SLIB's require procedure, and how should it interact with compiled programs? Yes, I've seen this, but what does "the corresponding files will be loaded" mean?

Ok, ok, trick question. My point is that SLIB's require procedure is specified in a way that seems to defeat the whole desire that I stated above.

In this context it is static vs dynamic.

The Scheme reports have always made an effort to give compilers a fair chance of producing efficient code. In some situations more analysis is needed than in the classic static languages, but nevertheless generation of efficent code is possible.

As a case in point consider the Stalin Scheme compiler, which uses whole program analysis. Stalin is famous for producing *very* efficient code, but the compile time is very long, due to the extensive analysis.

With the module system in R6RS it is now possible to analyze each module seperately. I therefore expect Scheme compilers will generate more efficent code than was (practically) possible in R5RS.

The Steering Committee and Editors had a political option that they chose to not exercise

The editors did not have such an option, except by petitioning the Steering Committee (just as anyone else could do) or by resigning.

My read of the community is that it would have had an almost 100% approval rating among the voters in the ratification process.

I doubt it.

So, if you want to look to the very public process here as a paradigm of how language standards are created

That doesn't make much sense to me. The Scheme situation is highly unusual for a variety of reasons, and the biggest problems it has faced are not even on the radar of most other languages.

You haven't persuaded me.

I meant the editors and steering committee acting in union could have dissolved and then reconvened under a different flag. I didn't mean that the editors had that power on their own.

I can't argue with your read on 100% approval. I'm just calling it like I see it.

I'd love to chat the third point ("Scheme's uniqueness") with you over a beer or some moral equivalent but it would be a rat-hole discussion on LtU so I'm happy just to have our differing opinions presented rather than contested.

-t

The Scheme situation is highly unusual for a variety of reasons, and the biggest problems it has faced are not even on the radar of most other languages.

What are good places to learn more about this (unlike Thomas, I do not mean your favorite pub :) )?

I'd say the archive of the rrrs-editors list has the best blow-by-blow account of the peculiar issues facing scheme. It's dated, but R4RS didn't resolve much, and R5RS even less. I'd say further that the partial success of the SRFI process is what made R6RS possible.

...Scheme++

:)

On a serious note, I would expect that many implementations of Scheme to continue to provide backwards compatibility, so that if programs are dependent on R5RS and/or their author(s) choose not to migrate to the new version, they can continue to target R5RS scheme.

At any rate--it will be interesting to see if a significant fork does develop, with large numbers of the "no" faction refusing to support the new standard (up to developing a competing version which is more to their liking). I hope not. OTOH, refusal to migrate is often a common issue when PLs (or any complex system) are revised, especially those which are "owned" by a community rather than by a single vendor or BDFL. In the C world, I remember lots of folks refusing to embrace ANSI/ISO C when it was standardized way back when--considering things like function prototypes to be a crimp in their style. And likewise when C99 came out; it got howls of protest from lots of people (especially those who objected to various C++ incompatibilities it allegedly introduced).

On a serious note, I would expect that many implementations of Scheme to continue to provide backwards compatibility

I fully expect that many implementations will continue to look just as they always have, but will allow the importing of R6RS libraries. R6RS doesn't define the entirety of Scheme any more than R5RS did.

(+ Scheme 1)

Maybe I'll create a programming language called "<p>", just to drive browsers nuts. :)

"But judging from the results of the vote, with about 2/3 in favor of R6RS, the comments on comp.lang.scheme are not representative of the Scheme community."

What makes you think that vote was more representative of the Scheme community? Esp. when the majority of implementors voted against ratification.

I understand you as asking how to define the Scheme community. Who are we? Without knowing who the members are, it would seem quite impossible to make claims about the majority viewpoint.

First of all, I hope we can agree that users, and not just implementors, are members of the community. This seems to be the understanding of the Steering Committee, which invited users as well as implementors to register to vote.

Secondly, you claim that a majority of Scheme implementors voted against R6RS. This is not quite true, as far as I can tell. While it is true that of those implementors who voted, 6 voted no and only 3 voted yes, the implementors of another 6 Scheme implementations abstained from voting. Shall we interpret these as no votes, or "don't care" votes?

While this is an interesting and difficult issue, I think the burden is on those who think those who registered to vote do not fairly represent the Scheme community. Or that those who post messages to comp.lang.scheme are more representative.

Any Schemer worth their salt has, at one time or another, written their own Scheme implementation - it's a rite of passage. Yet, the universal truth still holds that programming language design is *hard*.

Some PLs have their BDFL (benevolent dictator for life). Others have commercial vendors that dominate the process. What is most interesting about the Scheme RnRS process is that it was designed on a democratic model (democracy being the worst form of government, except all the others that have been tried).

So one question is whether Scheme would be better served having a meritocracy form of governance - some votes or more equal than others? Or should there be a separation of powers (aka a Republic), somewhat akin to requiring 2/3rds of the states (implementors), a majority of the electorate (voters at large), and a Supreme (Steering) Court?

I would have preferred a system where a supermajority of implementors (of publicly distributed Schemes) would have to agree to implement R6RS. That would guarantee wide adoption and a level of competence among voters. Non-implementing users who objected to the standard could petition the implementors of their choice.

A problem with this is that there are a great number of Scheme implementations that aren't particularly actively developed but still linger on. Indeed, I believe the number of Scheme implementations harms the community by diluting the active developer pool amongst many incompatible implementations. R6RS will help this by allowing greater code portability, and, I suspect, killing off some of the minor implementations.

R6RS will help this by allowing greater code portability, and, I suspect, killing off some of the minor implementations.

As the spec gets larger and more complex to implement, people who might want to implement a "minor version" of a Lisp, are now less likely to choose to implement Scheme. I think this is good. Perhaps this will lead to more little Lisps with new ideas. Kind of a devil's advocate angle, but there you go.

While I believe differently than you in this topic, I made no claims I feel the burden to defend. My question was not a rethoric one: I honestly don't know either way. I admit it was phrased aggressively, for which I apologize.

Regarding majority of implementors: My bad- I meant a majority amongst those implementors _which voted_, not an absolute majority.

I won't put words in the mouth of those who didn't vote, but I definitely wouldn't count an implementor's vote as "don't care" in any case, esp. considering they explicitly registered their interest in first place. If I was to pick a neutral word, it would be "undecided." In any event, the fact that both abstention and rejection each double acceptance between the implementors is alarming enough, IMO.