Slashdot Mirror

John Cowan recently gave a talk on the progress of R7RS (slides), the next revision of the Scheme language standard, at LispNYC. After the R6RS debacle, the community stepped back and is now basing the next standard on R5RS; the work has been split into two languages — R7RS-Small and R7RS-Large. The first working group is preparing to issue a final draft of the R7RS-Small language (PDF; clocking in at 73 pages vs. R5RS's 50) within the next few weeks. Read on for a summary of the planned changes to R7RS (more or less in the order of presentation). The talk details a number of improvements over R5RS and R6RS, and is divided into two portions. The majority of the talk discuses the status of the small language, with the last portion giving a quick update on the future intent of the large language group.

First on the list of major new features is a mandatory library system designed to be easily implemented atop existing module systems. R6RS's library system proved to tackle too much at once and be incompatible with everything already in a use (a persistent concern in the design of the R7RS-Small language). The R7RS system, on the other hand, is static, simple, and just powerful enough to promote implementation of portable libraries.

Exceptions are stripped down from R6RS (which proved too incompatible with existing implementations for practical use). guard (similar to try...catch in other languages) and with-exception-handler are supported: the latter runs the handler in the context from which the error was triggered (permitting recovery from the error like invoke-restart ) Unlike r6rs, exceptions lack a strictly defined hierarchy and can be any object (you could e.g. throw 4 if you really felt like it).

Dynamically scoped variables, in the form of parameters, are now part of the standard. Unlike Common Lisp special variables, parameters are first-class objects bound to expressions rather than symbols that are declared dynamically scoped. For reasons of simplicity it was decided to make parameters immutable (i.e. any "mutation" has to be done by rebinding). This has the (intentional) side-effect of making parameters play more nicely with threads (when mutation is permitted, setting a parameter that has not been rebound in the current thread requires synchronizing all threads and can have unexpected results).

As expected, R7RS includes bytevectors to complement strings. The small language standard only permits accessing bytevectors as ordered sets of unsigned 8-bit values (the large language standard will offer more flexible access). Binary I/O is implemented via a set of parallel procedures (open-binary-input-file vs. open-input-file, etc.) in contrast to the incredibly complicated dual binary/text ports provided by R6RS. Additionally, string and bytevector ports similar to SRFI-6 are provided instead of the incompatible string ports provided by R6RS.

Taylor Campbell noted that integer division in most languages is insufficiently expressive, and so R7RS will provide Euclidean division and centered division in addition to the usual suspects. Mathematicians rejoice!

As with R6RS, Unicode support is mandated. Unlike R6RS, the only characters that must be supported are those present in ASCII. For supported characters, Unicode case mapping and normalization are mandatory. One interesting diversion from Unicode and R6RS is that string order comparison is implementation-dependent: this gives implementers latitude with the internal encoding of strings.

Any user of Scheme knows that the language strives for consistent and obvious names for bindings. R7RS furthers this goal by resolving the long-standing inconsistency with core data structure creation, copying, mutation, mapping, etc. Lists, strings, and vectors now have a consistent set of each: make-TYPE, TYPE-copy, TYPE-set!, etc. Conversion procedures between all three types are also provided.

Finally, number of minor improvements were made. Most notable: record types are compatible with SRFI-6 (widely in use today); case sensitivity is the default (with optional insensitivity via include-ci); s-expression and nested block comments were added; IEEE infinities and NaNs have read syntax; strings may contain C-style escape sequences; Common Lisp circular list notation is supported; and common extensions to syntax-rules were standardized.

The final 20 minutes of the talk were about the status of R7RS-Large.

The R7RS Large language is currently on hold, mostly because all the small language members are on the large language committee as well, so there is a lack of time to work on both simultaneously. Work is planned to resume upon release of the final draft of the small language. Some work, however, has been completed.

The main focus of R7RS-Large is providing Scheme "with batteries included." John Cowan started the process by looking beyond the Lisp and Scheme communities (Python is mentioned) to figure out which libraries modern programmers expect their language to include.

This resulted in a list of around 250 packages that was narrowed down to around 80 packages through an initial voting process. It was decided then than some desirable packages (e.g. a foreign function interface) had to be omitted due to complexity. It is expected that implementers will continue experimenting and gradually come to a consensus on the larger packages using the existing SRFI process, and perhaps another revision of the standard down the road.

Of the packages planned for inclusion, the most prominent are: networking, threads, regular expressions, delimited continuations, URI handling, date and time parsing/arithmetic/formatting, hash tables, ambient environment access, file system directory access, gettext (i18n support), and pattern matching.

Most will be optional; packages will only be made mandatory if a number of the other packages require them. A compliant R7RS-Large implementation will only have to either provide a package fully or not at all (half implementations are forbidden).

Interestingly, R7RS large with all packages will be even larger than Common Lisp.

To avoid getting bogged down in stylistic discussions, a decision was made to focus on functionality above other concerns. The resulting packages may not be aesthetically pleasing to everyone, but will provide useful functionality. Users who disagree with naming, scope of functionality, argument ordering, etc. will be free to use the library system to import only the bindings they want, rename functions, wrap things into the style they want, etc. Basically, a compromise between the MIT approach and "Worse is Better" is being sought.

Here a call for volunteers is made: Since the focus will be on functionality over pure aesthetics, developers outside of the Lisp and Scheme communities are actively encouraged to participate in the R7RS-Large language process. No fixed time commitment would be required; the goal is to get a lot of people involved with a few core members maintaining momentum and guiding the process. The R7RS-Large language is most definitely a language designed by and for developers. So, make your voice heard!

Overall R7RS is shaping up to be the standard R6RS should have been (which, of course, could not have happened without the lessons of R6RS). The split between an elegant core language with each design issue meticulously fretted over and voted upon and a looser library standard should, hopefully, result in a core language that will stand the test of time with a standard library that can be used to get actual work done.

Nochiel writes "What is open source and why should businesses care? Why is innovation important and why isn't our company innovative? Why does it seem like everyone else is innovating while we aren't? How can we leverage Open Source? How can we implement an Open Source business strategy?" Read on for Nochiel's review. Innovation Happens Elsewhere: Open Source as Business Stratgy author Ron Goldman and Richard P. Gabriel pages 377 publisher Morgan Kaufmann Publishers rating 8 reviewer Nicholas Ochiel ISBN 1558608893 summary How to introduce open source into the enterprise as a viable and valuable business strategy.

This is a book about open source in the enterprise. It seeks to answer those questions and more. Finally, the Open Source Process has been codified in a manner that gives management the business perspective they have been yearning for.

Too often, Open Source come across as a religion. Ron Goldman and Richard Gabriel, through their sober treatment of the topic, successfully detail all the pragmatic aspects that a business should consider.

This book, to paraphrase the authors: ..is for anyone interested in a better understanding of open source--its larger history, its philosophy--, and its future prospects.

It is licensed under a Creative Commons License and is available at this link.

Chapter 1 presents the problem that the modern enterprise faces, namely: how to ensure high levels of innovation and productivity.

The reader is then introduced to the "innovation happens elsewhere" problem: High productivity requires doing less in order to produce more. This, in turn, necessitates being able to leverage other individuals'/companies' efforts. A company, therefore, has to recognize that there are more innovative forces outside the company than in it. By using these forces, a company can maintain a competitive edge. Open source is then presented as a solution to the problem.

The rest of the chapter opens the readers mind to the "new" new way of doing business., illustrates why open source is a viable business strategy and introduces the most important aspect of open source: community.

Chapter 2 discusses the "innovation happens elsewhere" dilemma in even more depth. The authors have a keen understanding on the power of the Commons and how it can make a difference.

In order to illustrate how the Commons can make a difference, the authors use the history of the Web as an example. They highlight the fact that it was built as a volunteer effort with no central planning and a small set of simple protocols. The growth of the internet then came primarily from volunteer efforts.

In this chapter, the authors successfully illustrate that a modern business can succeed only by leveraging the creativity of the Commons and engaging in conversations with a broad and dynamic set of participants in the given problem space.

Chapter 3 then tackles the most important question that managers ask: What is Open Source?

This chapter details the philosophical tenets of open source, the root of the zealotism as well as the history of open source. Many readers will find it interesting that, in the past, open source was the default methodology for leading software and scientific work!

Common myths and misconceptions are also addressed. The authors also provide an interesting comparison of the open source and agile methodologies showing how open source borrows from the strengths of the latter.

The secret sauce in open source is revealed and the various sections along the open source continuum are discussed. In particular, the authors address the value of gated communities and internal open source, a valuable discussion for those managers who wish to introduce open source into their company slowly or even extract value from only a subsection of the open source value chain.

This chapter is a complete description of the open source phenomena. As such, it can easily stand on it's own if one is looking for a quick primer.

Chapter 4 concerns itself with the business reason for adopting open source, how to develop an open source business strategy and how to create a business model that supports the open source strategy. Sun's NetBeans platform is used as a case study to illustrate the various aspects of an open source business.

This section gives possible reasons why you should open source your product as well as why you should use open source. This chapter is directed at the business strategist who wishes to understand how to implement an open source strategy and measure it's success.

Chapter 5 provides a discussion of the legal aspects of open source. It details the nature of a license, the structure of copyright, patents and types of licenses. It also covers multi-licensing, contributor agreements and licenses for documentation.

Chapter 6 concerns itself with the workings of the open source development process. An open source product is not so different from a proprietary one. It has versions, minor and major releases as well as a typical product life cycle.

The differences, where they do arise, are in the new infrastructure (and management of the same) as well as the additional responsibilities that developers are expected to take as they engage the community.

The authors also discuss joining an open source project. In particular, they emphasize that it is valuable to join an existing project if that project is already targeting the niche/functionality you wish to address with your project. This is important because it generates goodwill within the community.

Finally, open source within the company is discussed with case studies from IBM, HP and Sun.

Chapter 7 makes note of the fact that open source initiatives generally begin with middle management. As a result, middle managers encounter a number of challenges: The need to convince upper level management, get approval, acquire resources and set up the infrastructure.

This chapter provides valuable advice and strategies for individuals in this situation. (I wish I had read this chapter while at my previous employment. It would have saved me a tonne of grief.)

Chapter 8 assumes that the project is up and running. The mailing lists are functional and the public repositories are bursting with bleeding edge code. How, then, do we harvest the innovation that is happening elsewhere and build momentum?

After reading this chapter, the reader understands the value of marketing and community outreach. This is particularly valuable especially because it comes from two prominent members of the Sun community. (Sun, is the king of marketing. Their marketing efforts have made Java a household name and tool.)

Chapter 9 provides a summary of the gotcha's at various stages in the open source journey. At first, this chapter seemed superfluous as it repeats much of what has been said in previous chapters.

Upon review, however, the chapter becomes useful as a reference guide for managers as they tackle the problems that arise during implementation. The section on "recovering from mistakes" is particularly useful because a proprietary closed source company is typically used to hiding it's mistakes from customers and the world at large. The authors emphasize that it is important and valuable to fail in public especially if this failure is accompanied by an effective solution.

In Summary the title of this book is deceptive. I would have been better titled: Professional Open Source: A Manger's Guide. It is a lucid and accurate treatment of the topic.

The authors' concept of the commons is very interesting. It is one composed of things whose basic value is not diminished by making a copy. This, in my mind, is amazing! Does this mean that all projects should be open sourced? After all, software increases in value proportionally to the number of people to whom it's distributed.

The book also manages to dispel the myth of first mover advantage. In fact, first mover products rarely have the required quality to dominate the market. Perhaps this explains why open source products are rapidly eroding the market share of established applications. The proprietary stuff was a first mover relative to open source. It's quality was so bad that open source now presents a mature solution that actually works! (I can't help thinking about Zimbra in that regard)

Perhaps the most important message of the book is that there are smarter people in the world and they don't work for you! To paraphrase the authors:

Regardless of how smart, creative and innovative you believe your organization is, there are more smart, creative and innovative people outside your organization than inside. In addition, the majority of elsewhere doesn't particularly care to make products in your space.

This book should be at the bedside of any manager who is either delving into the open source world, wishes to understand what open source has to offer or seeks to clarify why open source as a business strategy will erode the market share of proprietary companies."

Hell O'World writes: "Wow! Mob Software." A concise submitter, how refreshing. To elaborate: an essay whose author argues that large software projects should be built, well, by a mob.