Pursuant to the ratification procedure, here is the final listing of the R6RS electorate:
I have been a Lisp user for more than twenty-five years, and a Scheme user for twenty years. My stake in the outcome of the Scheme standardization process is that I develop Scheme implementations for my own use, and am in the habit of releasing them as shareware as a public service. (My releases to date are all for the Apple Macintosh. They include Pixie Scheme, with several R3.xx releases in 1988-1991, and more recently Wraith Scheme, which started as R3.99 and has just made it to R5. Unreleased, but potential candidates for release, are versions of Wraith Scheme that run in a straight Unix shell, one with and one without the help of ncurses.) Clearly, I can create whatever software I like for personal use without worrying overmuch about standards, and clearly, there are enough well-established Schemes that the community would not suffer unduly for lack of my efforts (unless perhaps someone likes my user interface or documentation). Yet there is virtue in using an established standard as a base for development; namely, that if any of my explorations and side trips should be of general interest, the community will better be able to investigate and evaluate them if they are presented as enhancements to a standard rather than as additions to something that wasn't quite Scheme in the first place. For that reason, I have consistently tried to make sure that the Schemes I create contain a core that closely follows a recent "rn" report, with clear documentation and user-friendly features, and with such enhancements as I have made all precisely described, carefully documented, and constrained to a well-defined namespace. Since I hope to continue this practice in the future, I am consequently concerned with the continuing development of Scheme standards, for they are the standards I would like and intend to underly my own implementations. I hope this line of reasoning qualfies me for a vote on R6. (I note that notwithstanding much, er, discussion, there is no indication in the registration instructions that my statement of interest is supposed to say what I think of R6; I am not trying to be coy, I will tell you if you want to know, but the wording of the registration stuff does not seem so to indicate.
I am an active Scheme user since the early R4RS days. The day I got my hands on a copy of R4RS I knew I had found the language I had been looking for for many years. R5RS Scheme is what LISP always should have been: a bridge between lambda calculus and applied programming. It adds some interesting features, like continuations and hygienic macros, but manages to keep a small footprint, which is reflected by both its implementations and its standard documents. Scheme is a local optimum for expressing algorithms in an abstract and portable way. This is why I introduced Scheme as the principal implementation language on my CS and programming web site a few years ago. The web site carries Scheme-related information, software, and documents. Among other things it provides the full text of my introduction to functional programming in Scheme (also available as a book), PS/Tk (a portable Scheme interface to Tk, which I maintain), two toy Scheme implementations, and lots of Scheme code. Scheme is also my language of choice for implementing commercial software, and I plan to promote it as an extension language for professional customers in one of my projects. Finally, I think that Scheme is an ideal teaching language, because it encompasses all essential abstractions without adding any useless load. My future textbooks will definitely use Scheme as their implementation language.
My interest in Scheme is quite practical: I have found it to be a language that I can write efficient, maintainable and beautiful programs in. And I have done so, in a production and commercial environment. Most recently, I developed Tenspotting (http://tenspotting.com), a Web 2.0 application written in Scheme using the SISC implementation and the SISCweb library. I am absolutely sure that I had linguistic advantages by using Scheme rather than Java, PHP or other available options. Previously, I have used Scheme as a scripting language for front end of a Java web application. By using Scheme myself and my team were able to quickly add functionality to the application that would have otherwise required significant Java development. By making use of Scheme we were also able to leverage a network based REPL, which allowed us to interactively update the application on the fly. Along with on-the-job uses of Scheme, I have also benefited immensely from the lessons I have learned while studying Scheme related material. Topics such as what makes a well defined abstraction, OO, threading, distributed systems, lexical vs. dynamic scoping, are all general purpose topics that were made much clearer through studying them in a concrete Scheme environment. I look forward to using Scheme in additional projects, and I am quite appreciative to have even the smallest impact on its growth and improvement.
The Scheme programming language has provided an interesting medium for investigating programming language design, teaching the art and craft of programming, and constructing useful and interesting software. I personally use Scheme, in a number of dialects, to persue all three of these practices. The standardization process that led to R5RS resulted in a very intentionally designed, clean but sparse language representing a set of widely accepted and mature language features. Individual implementations of Scheme and Scheme-like languages have continued to explore aspects of language design and have arrived at new widely accepted but non-standard features. I use many of these features in my work, and I am not alone. I would like to see their acceptance expressed in an updated language standard, and their representation made consistent across implementations. I have no misconception that a new language standard will be perfect: no language standard has ever been. Nonetheless, standardization has the potential to advance Scheme and my work by documenting the lessons learned since the last standardization, decreasing the unnecessary differences between implementations, and providing a new platform from which language designs can be started, programming can be taught, and software can be crafted.
I am a computer science professor who uses Scheme extensively in my courses. I teach introductory-level programming courses (for each of novice programmers and die-hard non-functional programmers) and upper level/graduate courses in programming languages. I touch on several topics that are unique to, or best suited to, Scheme, including macros, continuations, and quote/quasi-quote. These have allowed me to give students a whole new perspective on both web programming and domain-specific languages. I want to see Scheme thrive as a language because of the value these exercises give to the students who are open to them. We are all familiar with students who reject Scheme as a mere "teaching language ". Those of us who use this language know that Scheme is neither trivial nor dead, but keeping the language alive through a healthy standard matters to keeping the language fresh and usable for realistic programming tasks. Students who see and like the language want to be able to use it for non-curricular programming. The standardization process says that Scheme continues to be a language worth developing. I strongly believe in this view and am registering to vote to keep this process alive and well.
I have been a professor at the University of Waterloo since 1988. For the past few years I have taught an introductory programming course to CS and Math majors using Scheme. By the fall of 2008 we expect to have over a thousand students a year moving through courses using Scheme. I have also used Scheme for various administrative tasks related to teaching (generation of Web pages, slides, course handouts, checking and typesetting of logical proofs). My interest in this standard is not just to ensure that Scheme remains the best introductory language for computer science that I know of, but to ensure that I am able to demonstrate to students how it can form a valuable part of their toolkit, both for upper-year courses and in their professional lives. I will be reading the final draft of the standard and the discussions surrounding it to try to decide if the standard preserves those features of Scheme I find valuable (clarity, concision, and a smooth learning curve that avoids needless complexity or obscurity) while enhancing the previous standard in ways that will facilitate the deployment of Scheme in the ever-increasing range of uses to which computers are being put.
My primary interest in the Scheme standard is its the potential to make my work, in terms of Scheme libraries and tools like PLT Scheme, more useful to a wider group of programmers. I will vote in favor of ratification, even though the document has technical flaws --- and even though it says too much about some things, too little about other things, and includes some design elements that could be much improved. On these general opinions, I have lots of company, but opinions vary on which parts are too much, which parts are too little, and how the design of various pieces should be improved. In the end, it's a compromise. Further discussion and work will certainly lead to a better compromise and a better candidate standard. Of course, any improvement will also preserve many flaws. It seems to be human nature, when faced with the certainly of imperfection, to think that if we at least fix X and Y (for whatever X and Y one happens to care about), then everything will be good enough --- while not fixing X and Y means certain disaster. In reality, it's rarely so simple; consider the last few 5.9x drafts, which attempted to fix a few Xs and Ys, but created little perceptible change in the community's overall opinion of the draft. Moreover, I see few examples where an implementation, specification, or user community collapsed due to one or two wrong details. Utter collapse and significant progress both take time. Looking back from this point in Scheme's history, collapse seems to have a head start. The 5.97 compromise is progress. Let's name it `R6RS', start getting more practical experience with it, and start working on a better standard named `R7RS'.
I use several functional programming languages professionally. Right now, Scheme isn't used for any of the projects for which I'm paid. It's been supplanted by languages with better standard support for modularity. These are mostly ML dialects such as OCaml and Haskell. I'm being burned by reliance on single implementations there (INRIA OCaml and Glasgow Haskell). I'd like to use Scheme for many purposes. It sure is easier to embed a Scheme than to embed one of those languages! I also value the ability to quickly explain very basic Scheme to users. This is the same feature that made Scheme attractive for GNOME Guile and Lua attractive for World of Warcraft. For this use, I'm most interested in a Scheme standard that is big enough to provide the features I want, like libraries and modules, without burdening implementors enough to distract them from building the nonstandard features I want, like concurrency and type inference. I am also interested in Scheme for education. Having benefited tremendously from SICP as a student, and from a broad base of SICP-educated students while teaching higher-level students, I am particularly interested in maintaining a language that can be shown in a very simple way, support better tools for advanced students, and avoid the contempt of students who see customary commercial languages.
A standardized module system for R6RS is important to me as an educator, because of the long current shadow Java & O.O. is casting -- when some people claim "classes are necessary for exporting names in a controlled way", many current students have no reason or experience to disbelieve that. Scheme, as an syntactically elegant language with minimal syntax, is one which can be pointed to as an alternative, providing defense against "OO is a necessary paradigm for all languages". Moreover, it's healthy for a language as a whole to have a reasonable language standard which is broad enough to provide industrial-strength features which are portable across several major implementations. Sure, if the language standard is too difficult to implement or does things poorly, then it can be bad for the language's acceptance, but much worse is to not have a standard at all, for necessary features in large-scale programs. Evidence that use of modules is pervasive -- and therefore an issue which should be dealt with by the language standard -- is that to check the word count of this submission, I loaded the regular-expression library...
The Scheme programming language is an elegant language that deserves to be continued. I believe that it is in the best interest of programmers at large that scheme should be revised to keep up with the current definition of what a programming language is. Scheme demonstrates that languages can be made to do the right thing and still be an effective programming language. A great deal of language innovations have been introduced in scheme and through its revision we can hopefully introduce more. What I like about scheme is the fact that it is a language that is based upon a small set of primitives and language features are not just mindlessly tacked onto the language but instead thoughtfully added to the language. This is what I hope that will continue to be a part of the language and is my personal stake in the outcome of the scheme standardization process.
Scheme is a loose confederation of languages, with a well defined core. R5RS has been the core definition of Scheme for many years, and could concievably serve as a core for many more. But it shows its age more with every passing one, and certain omissions (structs!) now seem fairly appalling. Naturally, these omissions don't prevent the individual implementations of Scheme from adding these features. However, each implementation will almost certainly differ from all the others in the particulars of these features' implementations, and over time the languages will diverge until Scheme seems less a language than a set of guiding principles. For this reason, I strongly support the ratification of R6RS, perhaps more as a simple statement of unity than as a set of new language features. I earnestly hope that R6RS will bring the Scheme implementations closer together, so that--as a DrScheme user and sometime author--I feel less as though I'm traveling in a foreign land when I use Gambit, or Scheme48 (or ...). Many thanks to the current committee, and all their hard work. (I'm over the 150-word limit before this paragraph, so I no longer feel that I have to stick to the topic at hand.) Again, thanks.
(string-append "I use Scheme as my primary computing language since 2003, and I have used it for academic research and enterprise software development. I have used several implementations for different projects, including Gambit, Chicken, Guile, STklos, and PLT Scheme. I have worked on several applications developed in Scheme, including applications for Speech Processing, Data Mining, Digital Signal Processing, Medical Diagnostic and Artificial Intelligence. The areas of the language I am most interested in are domain-specific languages, compilation issues, libraries/modules systems, foreign languages interfaces, and parallelism." "I adopted Scheme because it allows me to express the paradigms of many programming languages using just one language (e.g. symbolic programming, functional programming, object-oriented programming, logic programming, etc.). It is an excellent tool to learn all these concepts and use them to develop robust and powerful software. I like the simplicity of the language and find very interesting the large variety of Scheme flavors available on the web. R6RS could have several implications regarding the nature of the language, and that is why I want to vote.")
I'm the implementor and lead-maintainer of CHICKEN, a popular Scheme implementation. I do not support R6RS out of following reasons: it introduces arbitrary and redundant language constructs into a language that has been designed from the start to be minimalistic. The minimalism in Scheme was and still is the base which distinguished it from all other languages and makes it an excellent experimentation platform and language design tool. Minimalism is the very essence of Scheme: to express as much as possible with as little as possible. Designing such a thing is naturally extremely hard which made the original authors of the Scheme report (quite wisely) to decide on only making changes with unanimous consent. R6RS does away with that process and tries to remodel Scheme as some sort of mainstreamish language and so completely removes itself from the roots that make Scheme what it is. R6RS will improve cross-implementation portability, but not by deliberate language design, but by artificially reducing the number of conforming implementations. R6RS has not adapted common and widely used SRFIs, yet includes less used or even obscure fringe SRFIs (mostly by one author, who incidentally, is member of the R6RS committee). In my opinion, R6RS shows disturbing signs of dilettantism in the selection of language features added to the report: arbitrariness, unnecessary syntax constructs where procedures would do and completely redundant language features. It sucks, folks - face it. DEAR SCHEME USERS: DO NOT ADOPT R6RS! SEVERAL MAJOR SCHEME IMPLEMENTATIONS HAVE DECLARED NOT TO SUPPORT IT, WHILE NEARLY ALL SCHEME IMPLEMENTATIONS WILL STAY R5RS COMPATIBLE OR PROVIDE R5RS COMPATIBLE MODES IN THE FUTURE. DEAR SCHEME IMPLEMENTORS: DO NOT ADAPT R6RS! DON'T WASTE YOUR TIME RUNNING AFTER A BROKEN STANDARD WHILE YOU COULD HELP YOUR USERS MORE BY ADDRESSING REAL PROBLEMS.
I learned Scheme while taking MIT's 6.001 and have been a fan ever since. I even went back and read all of Guy Steele's 'Lambda: The Ultimate' papers. Since I was a student, my professional programmer 'hat' and my programming language semantics/aesthetics/mathmatician 'hat' have frequently been at odds. A number of times when I tried to use Scheme for a project, I would invariably wish Scheme had a rich set of standard 'libraries' like Common Lisp so I wouldn't have to re-invent the wheel, even though CL has never been as elegant, and certainly suffered from committee-itis through its development. Recently, there have been (proposed) changes to the Scheme standard, like case-sensitivity, that (to me, at least) go against a long-standing tradition, though I do understand that most modern languages are case-sensitive. There are other changes that I think are 'the right thing.' I am very happy with the direction that Scheme macros have gone in. I wish there were better hooks/tools for debugging deeply nested runtime environments. In general, I am interested in monitoring the standards process in the hope that things don't get gratuitously out-of-hand.
My interest in the outcome of the Scheme standardization process stems from my 20+ year involvement with programming language design and implementation. I have been an implementor of optimizing compilers for imperative languages like C and Fortran, but my primary interests are in the area of functional and dynamic languages. I am the original author of the libscheme implementation of Scheme and the Marlais implementation of Dylan. I was introduced to Scheme by the book _Structure and Interpretation of Computer Programs_ and have followed its evolution through many implementations, research papers, and standards changes. One of the major problems I have faced when trying to write large programs in Scheme, is the lack of standard solutions to everyday programming requirements like tagged records. When starting a new program, I am forced to either manufacture my own records using tagged vectors, or learn a new record mechanism based on the implementation I am using. This is a big disadvantage that Scheme has when compared to other modern dynamic languages. I am very encouraged by the move to provide a standard library mechanism which will allow the core of the language to remain small, while making it easier to program in the large. One of the criteria by which we should judge this standard is whether it provides clear direction on how to accomplish basic programming tasks in a way that does not require building your own infrastructure, or resorting to implementation-specific features.
The release of R6RS is coming into a world of languages that have been getting closer and closer to Scheme in the past few years. With Java gaining more functional features, Python coming up strong, and Haskell gaining steam, the world is prepared for a properly designed and implemented Scheme. Of course, this next revision cannot expect to be welcomed. The prefix expressions and 'superfluous' parenthesis that makes the code-as-data paradigm so elegant is generally disliked by those who don't yet understand it. Scheme also has a reputation for being weak and slow, while implementations like Bigloo and Chicken are working to reverse that prejudice. R6RS is one more step towards general acceptance and usage. I hope to implement a Scheme compiler for R6RS. This compiler will initially be written in C++, targeting LLVM, and eventually be rewritten in R6RS itself. This makes me extremely interested in the standardization process, as a well-written standard makes the compiler design much more straightforward.
I'm a PhD student working on dynamically reconfigurable FPGA and the use of Scheme was a must because our system is running in embedded devices. I'm using Scheme for about 10 years. Scheme is important to me because it is a small and compact language, easy to learn and can be so expressive by using high-level features. I port Gambit on Xilinx FPGA and use its runtime. We are trying to implement a JIT compiler to produce on-the-fly hardware (configuration for a FPGA) and improving performances on some applications. Scheme is a good choice for studying compilers because it's easy to manipulate code as data (and vice versa). I wrote about 3 others compilers in Scheme, and I will continue to use it for its simplicity. So, I'm interested in the standard because I need more uniformity in the interface between runtime and applications. Actually, programmers do not choose Scheme language, but a specific implementation. The language is supposed to be portable!? The standard must give more effort on this lack.
My interested in Scheme is as both a programmer and an educator. As a programmer, I have been using Scheme since 1996 and I have used Scheme professionally for the rapid prototyping of language processors. For the professional programmer, Scheme should continue to offer useful languages features and the possibility of high-quality implementations. As an educator, I believe that (a) an introductory programming language should have a simple semantics with a minimum of syntactic baggage and (b) that the study of programming languages and their implementation is an important part of an undergraduate CS curriculum. Scheme has been successful as an introductory programming language. It serves very well as an implementation language for language processors, and as a realistic and interesting source language for them. The Scheme standard should continue address the requirements of programmers and educators alike.
As a computer science educator, I use Scheme (specifically PLT's DrScheme) along with the "how to design programs" curriculum to teach the art of programming to teenagers and kids as young as 7 years old. Despite its usefulness as a pedagogical tool, Scheme suffers from a number of problems. The struct syntax is clunky, it lacks important syntactic sugars (such as comprehensions), and most importantly, it lacks a coherent set of standard libraries for lists, strings, streams, resizable arrays, GUI, OO, searching, sorting, permutations and more. After initial concepts are learned, the next step in programming education is to learn about libraries -- what sorts of data structures and algorithms are typically available, and how do you use them. It seems a shame that my students can't do this kind of learning in Scheme. Ultimately, this prevents me from giving my students challenging, real-world problems to solve in Scheme, because without a base of well-documented, standard libraries, it becomes impractical to try to tackle these sorts of problems. Clearly, Scheme needs to grow as a language, and the standardization process is part of that growth and change. My hope is that the new standard will better allow for the construction of standard libraries, making my job as an educator easier.
I am a professional programmer, though I have not yet found a job that allows me to program in Scheme. I use Scheme for all of my personal programming. I have been active on comp.lang.scheme for many years, and am the author of SRFI-40 A Library of Streams (I am currently at work on a revision). Scheme embodies for me the perfect programming environment -- it allows zen masters like Oleg to write a mini-prolog, and lesser mortals like me to write csv parsers and sudoku solvers. I am interested in the R6RS process because I want Scheme to grow and prosper, but retain its jewel-like properties. I know from my work on SRFI-40 that writing a language standard is ridiculously hard work, constantly requiring decisions both great and small, and I applaud the committee for its great work. And I am very intrigued by the fact that the community is being asked to vote on the standard -- I don't know any other language that has done that, and it will be interesting to see what happens.
My stake in the Scheme standardization process is that of a user. I use Scheme in my work as a theoretical astrophysicist at MIT. Currently, I use Scheme as 1) a scripting language controlling computational codes written in another language (usually C) and 2) a prototyping language for codes which will eventually be re-written in another language (usually C). But, I think Scheme could be so much more than this. With macros and first-class functions, Scheme could be a premier scientific development language---a "domain-specific" language for every problem, with the power of closures, customized class and unit systems, and automated compiler optimizations through macros would be incredible. Unfortunately, Scheme is not there yet: the implementations fall into two camps (particularly with respect to macros). Either an implementation produces machine code which executes rapidly, *or* it has powerful syntactic and modular abstraction capabilities (with the possible exception of Chez). I am particularly interested in the R6RS module system and the numeric operators. Designed properly, and implemented, these systems would greatly improve the macro capabilities of the fast implementations, and possibly improve the speed of the "rich" implementations; this is a win-win situation for me. Based on this (relatively unique) perspective, I am requesting the capability to vote on the proposed R6RS standard.
Scheme has been my primary programming language for the past
three years.
I was drawn to it due to its elegant yet powerful core as well as
the
ready availability and accessibility of a great number of
implementations.
At present, I'm particularly well acquainted with the CHICKEN,
Gambit-C
and Gauche implementations of Scheme. I've also read a good deal
of the
available literature from the past three decades, and am on the
path of
graduating from being a mere user and contributor to becoming an
implementor myself.
My primary areas of interest in R6RS concern namespaces,
portability and
the standard library. Lurking on comp.lang.scheme and the R6RS
discussion
list for the duration, I've gained an appreciation for the tension
inherent between the desire for minimalism on the one hand, and
portability and practical usefulness on the other. I don't envy the
editors' task in attempting to strike a balance on the matter
given the
diversity of stakeholders involved.
R6RS seems to me a crossroads for Scheme as a programming
language, and
indeed for me personally; R6RS and its adoption by respective
implementations will determine whether I will stick with Scheme, or
whether I will set out in a diagonal direction, bootstrapping
from R5RS
to create something of my own.
Since the early 1990s I have worked on the RScheme implementation of the scheme language, primarily as a platform to experiment with language and system features such as object systems, modules, macro systems (see my 2002 Ph.D. dissertation on this subject), and persistent object storage. More recently, I have been using RScheme as a platform for rapid development of novel applications, to varying degrees of commercial success. My interest in the standardization process is primarily in how hard it will be to (a) support the new features required by the standard in RScheme (RScheme strives to be standard-compliant, although since R5RS the divergent macro systems have been troublesome), and (b) tweak existing and conflicting implementations of certain features (such as modules) to be compatible with both the new standard and with the RScheme install base of applications. I also currently serve as a SRFI Editor, so I have an interest in the standards-track Scheme insofar as it defines the platform upon which SRFIs are built.
We have used Scheme at our school Otto-Hahn-Gymnasium in Nagold, Germany for several years now. We used to work with various programmes in the course of years, among which were Pascal and Java. At that time we have learned that Scheme is much better for the training of students. Particularly the graphic user interface of DrScheme makes work for beginners with the programme very simple. You immediately get to the essentials with DrScheme without having to deal with a lot of unnecessary gadgets. It is especially the compact notation which really does help beginners and does support practical teaching. Sample programmes often are so short that they fit on one board or one overhead transparency so that explanations become easy as you can see everything which is importance at a glance. The notation is relatively easy for the learner as it is based on mathematical algebra. Thus you can easily link mathematics and computer science. As the computer language of Scheme is relatively limited, you can save a lot of time in contrast to other programming languages because you have to explain much fewer language elements. Neither the students nor the teachers have to deal with a lot of dead freight, which often distracts from what is really essential.
For me, Scheme is an excellent research platform, first because it is easy to adapt the language to support new features, but also because it includes features that are still areas of active research such as continuations or hygienic macros. I spent 7 years of research in the field of programming languages and most of the time, I used Scheme as my starting point. At the university, I have used Scheme for teaching students of all grades and in my opinion . For beginners, the teacher has the possibility to start with a small subset and extend the language gradually when new areas of programming and programming languages are covered. For advanced students, it is not only possible to teach features such as concurrency or object-orientation with little startup cost but also to show the implementation of these features within the language itself. So, Scheme is a ideal tool for teaching as well. The one thing that has been missing so far in the Scheme language is a portable framework for building real-life applications. Having to tailor my Scheme code to a specific implementation almost right from the start took away a lot of room for improvement from my programs in the past. I hope this will change real soon now and I will do my best to support the adaption of my favorite Scheme implementation, Scheme 48, to R6RS.
I am involved with Scheme as an implementor, researcher, educator, and user. My interest in the standardization process is simple: Scheme has been a useful language, at least for my purposes, and I want it to remain so. As the needs of the community and individual users grow, and as the world outside of Scheme changes, this means that Scheme must grow and change as well. Although views differ on the exact mechanisms, there has been a clear consensus since even before the features of R5RS were agreed upon 15 years ago that we need some sort of library system, some sort of record system, some sort of exception raising and handling system, and support for more general forms of syntactic abstraction. The need for Unicode support has become clear since. More generally, R6RS should support the construction and sharing of substantial, useful programs and libraries to a greater extent than did R5RS. Yet, any changes need to be made in a way that doesn't destroy the character of the language, inhibit research and development of new and improved language features, make efficient implementation unduly difficult, or make the language less useful for teaching. This is a difficult task, and I don't expect perfection. People have widely differing opinions for what constitutes a good standard, and even my own opinions differ by viewpoint. So we should expect compromises to be made and not to be happy with all of them.
I have two main concerns. The first is that R6RS specify a Scheme that increases modularity and fosters interoperability between implementations of Scheme, so that newcomers to the language will not be put off by differences, but rather will see more easily how to leverage existing code. I am particularly fond of the SFRIs and the PLaneT archives. The SRFIs are widely shared among implementations, and I'd be tickled if PLaneT could evolve via R6RS into a repository directly useful to more Schemes. Second, there is a tension between not wanting to scare off new users, and keeping advanced users interested in Scheme. Current experts love Scheme's role as a language with which one can create new languages, since the power of transformative techniques is almost unbounded. For Scheme to remain relevant and continue generating productive and lively intellectual debate, it must preserve its attractiveness to the expert community. If I put these two goals together, R6RS should make life a little easier for the newcomer or the software integrator, without taking anything away from the expert.
I've used Scheme (mainly Gambit-C) for over 10 years for several purposes: numerical computing (numerical methods for partial differential equations, image processing, graphics generation, etc.); education (student projects in numerical methods for partial differential equations, homework-on-the-web server for pre-calculus students, general computing projects by me and my graduate students, graphics generation, etc.); hobby/research (the Gambit-C bignum library, totally written in Scheme). My interest has generally been in speed of (unsafe) generated code, ease of debugging, full numeric tower, proper tail recursion, good support for numerical programming. For example, I added the first homogeneous vector implementation to the Gambit-C runtime and compiler (which Marc Feeley totally rewrote before it was first released to the public). Lately I've become more interested in having "safe" code run reasonably fast (perhaps I'm getting tired of debuging Scheme->C code with gdb). I've spent time and energy since 1998 in reconciling Scheme with the IEEE 754 arithmetic standards. In support of my extensive use of the Gambit-C Scheme->C compiler, I've participated in the GCC development process for many years, mainly by testing development versions of gcc on Gambit-C--generated code; this process has found several bugs and many inefficiencies in the algorithms used internally in GCC, and the GCC developers have been gracious enough to respond with better, faster algorithms. (Often, Gambit-generated code, which generally compiles a complete Scheme file to a single C procedure, was the first to truly exercise certain gcc algorithms, and so such extreme testing exposed O(N^2) or worse algorithms.) I also have an interest in random number generation, which is what motivated me to participate materially in the SRFI-27 process. So, my stake in the standardization process is as a heavy user, especially of numerical code.
I use Scheme to investigate various problems in programming languages and mathematics. I have an interest in preserving the aspects of the language that make it so elegant and desirable to use, and its location in the spectrum of programming languages and systems. Scheme, in its original and current form, serves as a excellent target for exercising implementation techniques. It also, like the lambda calculus which inspired it, provides a basis for modeling all paradigms of computation, favoring none. Scheme is the archetype of a language which reifies its internal constructs in a sound manner. Like the original LISP, its creation is a landmark in language design and implementation. In creating Scheme and RABBIT, Steele (and Sussman) showed that (a) lexical scope was efficient, (b) CPS is a feasible intermediate representation for compilation, and (c) the metacircular approach to developing defunctionalized interpreters described by John Reynolds was practical for designing and implementing real languages. In creating call/cc, they were ahead of their time in demonstrating what Sabry and Wadler formally described in "a reflection on call-by-value": that constructs introduced in the target language of a program transformation could be reflected back to enrich the source language. The ethic of parsimony in language design also was and is an important part of the Scheme language. As in mathematics and writing in other human languages, less is more when the right formulation is found. This ethic sets Scheme apart from most programming language designs. I am certain I am leaving out many reasons Scheme is an important language, but I believe I have given enough reasons to demonstrate a reasonable interest in Scheme. In particular, an interest that whatever language is blessed by the name of Scheme be true to the high standards and design principles of the original.
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. When, however, those weaknesses and restrictions have been excised, the programming language should be free to grow wings and fly. That time is long past for Scheme. Here is my stake in the Scheme community: Roles: Software designer and implementor. Textbook author. Educator. Community activist. Usenet prognosticator. Defender of the faith. Actions: Build real systems in Scheme on which I stake my reputation. Manage schemers.org. Coordinate TeachScheme! workshops. Jointly initiated SRFIs. Resources: - Books: How to Design Programs. Programming Languages: Application and Interpretation. - Software: DrScheme programming environment. PLT Scheme Web server framework. FrTime functional reactive language. Continue conference manager. Margrave access control analyzer. Resume faculty search manager. MzTake scriptable debugger. DivaScheme speech interface. XeLda unit-checker for Excel. - Projects: TeachScheme!. SRFI. - "Kickassing Genial" Talk: The Swine Before Perl.
I am both a Scheme implementor and user. Guile being derived from SCM, mine is arguably the most widespread Scheme implementation. As a user, I have stretched the envelope for Scheme to an incredible variety of applications, some of which are detailed below. JACAL is an interactive symbolic mathematics program. JACAL can manipulate and simplify equations, scalars, vectors, and matrices of single and multiple valued algebraic expressions composed of numbers, variables, radicals, and algebraic differential, and holonomic functions. In 1990 I converted my symbolic math system from Common-Lisp to R3RS Scheme in order to be able to run on small computers. George J. Carrette's SIOD: Scheme in One Defun compiled and ran on my computer, but wasn't a full Scheme implementation. So I converted SIOD into the last C program I would ever need to write: the SCM Scheme interpreter. SCM's approach is unusual; it is not a byte interpreter. Tom Lord describes it as "essentially a hand-compiled partial evaluation of a simple Scheme compiler coded in a lazy, functional style, composed with a simple, imperative and eager-style graph-code interpreter". Its approach is motivated by objective measurements of running time and startup latency as described in several articles on my "Computer Natural Science" webpage, http://swiss.csail.mit.edu/~jaffer/CNS. Other major contributors to SCM are Radey Shouman, Jerry D. Hedden, and Hugh Secker-Walker. I wrote SRFIs 58, 59, 60, 63, and 94, which are implemented in SCM. Since 1990 I have done nearly all my computing in SCM, which has extensions and libraries to perform tasks as varied as image-processing, scripting, and interactive HTTP-service. SCM is well suited as an extension language; and in 1995 became the basis for Guile, Project GNU's extension language. SCM development continues toward the APL paradigm of array (SRFI-63) computation. Instead of iterating a complicated calculation over each element of an array, an APL interpreter can apply primitive calculations to a succession of (temporary) arrays. These simple array primitives can be compiled (in the runtime library) to use native vector-execution operations. For programs operating on regular data structures of more than a few elements, the overhead of interpretation will then be negligible. Although this paradigm may use more memory than serial element replacement, the arrays will usually be compact in the cache. Radey Shouman has implemented some whole-array arithmetic operations in SCM. I hope the full APL set will eventually be supported by SCM and SLIB. APL computation in Scheme would reduce the interpreter penalty to the point that interpretation (versus compilation) would be sufficient for many scientific programs. APL, like Scheme, is a functional language. Unlike Scheme, most of its operators are inherently parallel. Incorporating APL primitives would seem the straighforward way to break Scheme's serial straitjacket. SLIB is the largest and longest collaboration facilitating portable (implementation-neutral) Scheme for non-trivial applications. Its breadth is comparable to libperl, but with higher quality, unified documentation, and better integration between modules. SLIB supports Bigloo, Chez, ELK 3.0, GAMBIT 3.0, Guile, JScheme, Kawa, MacScheme, MIT/GNU Scheme, PLT Scheme (DrScheme and MzScheme), Pocket Scheme, RScheme, scheme->C, Scheme48, SCM, SCM Mac, scsh, Stk, T3.1, umb-scheme, and VSCM. I founded the SLIB Scheme Library to supply those elements of the richer Common-Lisp function set which JACAL uses. SLIB has grown to encompass a broad spectrum of capabilities, from color to discrete-Fourier-transforms to sequence-comparison to relational-databases. SLIB is written in R4RS Scheme. How can it manage without a module system? Through the judicious use of prefixes in names; and because it is a curated (by Radey Shouman and myself) library. I wrote SRFIs 59, 60, 63, 94, and 95, which correspond to SLIB features. A talent with parsers and translators, all written in Scheme, has enabled me to work in the Scheme language through much of my career in electronic and software design. The SCM script "Schlep" (http://swissnet.ai.mit.edu/~jaffer/Docupage/schlep.html) translates a list-less subset of Scheme into ANSI-C code. Originally developed to implement the WB B-Tree C library, it has been used to implement complex Linux kernel drivers for video decompression boards. These boards were designed using the SIMSYNCH digital simulator (also in Scheme). The SIMSYNCH board simulations ran together with the Scheme kernel driver source, enabling early debugging and dramatically reducing hardware/software integration effort. And SIMSYNCH translated the Scheme circuit designs into Verilog or VHDL for logic synthesis. SIMSYNCH is a simulator for digital electronics at scales from chip to board. Design files are composed of Scheme definitions and expressions. These design files can be run as a Scheme program at high speed. SIMSYNCH has programs which translate the design files into formats suitable for logic compilers (MACHXL, VHDL, and Verilog). "Schmooz" (http://swiss.csail.mit.edu/~jaffer/Docupage/schmooz), also written by Radey and me, creates a TeXInfo (documentation) file from specially formatted comments at top level in Scheme source. The Schlep, Scm2Java, and Scm2Cs SCM scripts also produce TeXInfo files for their target language APIs. "Pas2scm" (http://swiss.csail.mit.edu/~jaffer/Docupage/pas2scm) translates Pascal programs to Scheme. On http://swiss.csail.mit.edu/~jaffer/Scheme, my scheme program rrrs2txi.scm translated the LaTeX r3rs, r4rs, and r5rs to texinfo format (r3rs.txi, r4rs.txi, and r5rs.txi), from which the online HTML versions were derived. WB (http://localhost/~jaffer/WB) is a B-Tree, sorted associative array library. It is fast and reliable, routinely handling database file sizes of several hundred MB. WB is a Scheme-intensive project. The source code is written in a list-less subset of Scheme; the test code exercising all the limit cases for block splits and deletes is written in Scheme. SCM scripts (Schlep, Scm2java, Scm2cs) are used to translate the WB Scheme source code into C, Java, and C#. The libraries compiled from these different languages (and databases created by them) inter-operate transparently. WB includes a SCM interface to the WB C-library and an identical interface to the (Scheme) source. Thus the same test code can be run against source and compiled versions. Other major contributors to WB are Jonathan Finger, Roland Zito-Wolf, and Ravi kiran Gorrepati. WB includes a higher-level SCM interface to WB which supports SLIB relational and relational-ISAM databases. With integer and IEEE floating-point numerical keys having numerical collation order, RWB-ISAM is well suited to storing and manipulating sparse numerical data sets. SLIB's database-interpolate module emulates continuous functions from stored measurements. A Numerical relational-ISAM database is used by FreeSnell (http://swiss.csail.mit.edu/~jaffer/FreeSnell/), a program which computes optical properties of multilayer thin-film coatings. Dielectric, metallic, and granular metallic films are supported. It includes utilities to create, manage, and query its large spectral refractive-index database. So, in addition to a large body of Scheme code for proprietary electronic design, simulation, and software, I have initiated, organized, coordinated and coded several large, multi-author, free software projects encompassing over 70,000 lines of Scheme code.
The world already abounds in more or less interesting programming languages, and turning Scheme into yet another one would constitute a real loss. Scheme ought to try capturing the platonic ideal behind these languages, and people should be justified in assuming 'This is the correct way, because this is how Scheme does it.' I certainly encourage extensions to Scheme to make it a practical general-purpose language, but such extensions should be clearly labelled as such: (preferably standardised) extensions, not Scheme itself. I have been programming Lisp since 1980, Scheme since 1985, and teaching it since 1986 or so, and I have always immensely enjoyed the awakening insight in my students: 'This is how programming is supposed to be!' Other languages often do things in a certain way because, well, one must make a choice, mustn't one?, but Scheme does it consistently because it is the correct way. Once that insight has come, the Scheme way becomes the *obviously* correct way - which of course often means: 'a certain way implemented in Scheme is the obviously correct way', but that's how it ought to be: in different situations, different solutions are obviously correct, but they always transparently reduce to the platonic assembly language - Scheme.
I am a senior research scientist at one of Europe's largest research organizations for computer science, the Fraunhofer Gesellschaft. (Fraunhofer is perhaps best known as one of the developers of MP3.) Most of my research has been in the field of Artificial Intelligence, on topics such as knowledge representation, nonmonotonic logic, planning and computer models of argumentation, with a focus on legal applications. I am the current president of the International Association for Artificial Intelligence and Law. I have been doing research in the field of AI since 1984. Scheme has been my preferred language for building research prototypes, starting with my work on OBLOG in 1986-87. (See http://www.tfgordon.de/papers/ papers.html for a list of publications.) Most recently I have used Scheme in a computational model of argument, called Carneades. An article about this work has been accepted for publication by the Artificial Intelligence Journal (in press). So my interest in R6RS is as a user of Scheme for over 20 years. My research is not conducted in isolation, but in teams, for example as part of European research projects with many partners. And Fraunhofer is expected to work closely with industry to produce innovative products. It has always been a struggle for me to have Scheme accepted for use in these projects, due to the small size of its user community, the small number of libraries and the lack of portability between implementations. In the 80s the struggle was with Common Lisp. More recently with Python and, especially, Java. I've been hopeful of a breakthrough for Scheme at various times over the years, for example when Apple announced its Dylan project, when it appeared Sun might support Scheme in a big way, before it focused instead on Java, and when Scheme was adopted by James Clark for use in the DSSSL ISO standard, in connection with SGML. (Incidentally, I may have had some small influence on the choice of Scheme for DSSSL. I was the developer of the qwertz document processing system, which used SGML, and was later used for the Linux documentation for several years. During this time James Clark and I had a brief email discussions about DSSSL in which I may have promoted Scheme.) My hope for Scheme is that it will become a viable alternative for building not only research prototypes but also commercial applications. Other languages used by industry are becoming more like Scheme as time proceeds. There is a renewed interest in functional programming, as evidenced for example by Microsoft's F# project, Sun's recently announced javaFX Script language and Martin Odersky's Scala language. Or the functional features of Python. None of these languages are better suited for my research on knowledge representation, reasoning and argumentation than Scheme, since I make extensive use of symbolic expressions and macros for building what has come to be called 'Domain Specific Languages', by extending Scheme. There is a window of opportunity for Scheme at the moment and R6RS, if adopted, would help Scheme to take advantage of this opportunity. Following the debates on the Scheme newsgroups, my feeling is that much of the opposition to R6RS is coming from some of the implementors (e.g. Bigloo, Gambit, Chicken, SCM). Although it would be a shame to lose their support, from my perspective as a user I would be willing to take this risk, if it is the price to pay to have a viable standard. Of course implementations are essential for viability. But, judging by the success of Java, Python, and Perl, for example, we do not need many implementations. A few good ones would suffice. If Chez, MzScheme, Scheme48 and Larceny would all work together to support R6RS, I am optimistic that Scheme has a good chance to succeed. I have no sympathy for those who want to keep the Scheme standard minimalistic and 'pure'. I do not understand why the interests of those who prefer such a small language are not already served by R5RS or even older versions of Scheme. Indeed, I do not understand why people primarily interested in teaching computer science or experimenting with programming language design require any standard for their work. Was the huge success of Abelson and Sussman's course on the Structure and Interpretation of Computer Programmers, which uses Scheme, in any way dependent on some Scheme standard? To be fair, my work also does not depend on their being a Scheme de jur standard, but only on there being some de facto standard. If R6RS fails, I can only hope that at least one Scheme implementation, preferably PLT Scheme, which I now use, grows and prospers, to become a viable competitor to such languages as Python or Ruby, which also do not have standards. It seems odd to me that the implementors opposed to R6RS might prefer this scenario, where they would lose all influence on the future development of Scheme.
I've been an active member of the Scheme community for over five years, participating in the SRFI process and contributing to a number of implementations, most notably Chicken and Gauche. All of my personal code, without exception, is written in Scheme; the HTTP server running my site is implemented in Scheme, and I've implemented an SMTP server, a text editor with vertical text layout, a video game, and numerous Unicode and linguistic utilities, all in Scheme. I've participated in the past 3 ICFP contests using only Scheme. I think in Scheme. Using multiple Scheme implementations has always been a source of difficulty for me, and I've tried many approaches to writing portable code, including the abandoned tongue-in-cheek "common scheme" project. More recently, in desperation, I've been working on my own compiler with C and native x86 ASM backends, and am deliberating which standard to align it with. This Fall I will begin graduate studies in computational linguistics, and intend to use Scheme for my research. Several other students in the lab use Scheme, and I hope to encourage its use even further. Standardization and interoperability of implementations is an important factor when proselytizing to a language. But mostly, Scheme is the only language that is beautiful to me, and I want to ensure that it stays that way.
I'm curious why a stake statement should be more original than 'I'm depending on this programming language for my daily work'. However, I'll try to be original. I'm currently using scheme to write business programs. Being practical, but also loving beautifull languages, I have adopted scheme some years ago, both because it is a clean language, but also because it is such a powerful language. The macro language is both clean and extremely powerful. It always makes me curious why so many people use Java, which is a cripled language compared to scheme. However, I'm also a practical guy. The scheme community is a scattered community. Everyone wants his or her own implementation of scheme. Because of this a new RSRx specification is in my opinion very important. The RSRx specification keeps scheme implementations at least somewhat standardized. Of course, the SRFI process also helps standardizing scheme implementations. I think, scheme programs should be easily portable between different scheme implementations and RSR6 will help that a lot.
We use Scheme in an electro-optics laboratory to efficiently develop and control precision devices such as telescopes and dynamic optical systems. Scheme could be used to improve more aspects of laboratory software such as data distribution, executive control of experiments, and algorithm research. However, programmers and managers avoid Scheme because they perceive languages like C++ and Java to be standards of the software profession. For broader acceptance, Scheme's elegance needs to be exploited to give it an obvious advantage over other languages: a genuinely portable standard that includes macro and library systems. The conformist languages have proven to be so cumbersome in the hands of typical programmers that scientists and engineers have gradually chosen to write much of their own software, leading to legacy programs that lack the wisdom that computer scientists could have provided. Scheme is an ideal language for the laboratory because novices could use it for concrete tasks like managing experimental data, yet experienced computer scientists could research more abstract problems such as creating programming environments for long term experiments. R6RS Scheme will enhance the argument that a laboratory that is critically dependent on computations can benefit from computer science as much as the physical sciences.
I have been using the Scheme language for teaching and small development efforts for over 15 years. More recently, I have been using Scheme, specifically PLT Scheme, to develop larger-scale knowledge-based simulation applications. Elements of this knowledge-based simulation capability have been released as open source software for use within the wider (PLT) Scheme community. Currently, in spite of the existence of a standard for Scheme and corresponding Scheme Request for Implementation (SRFI) packages, this level of production quality code is not readily portable across different Scheme implementations. For Scheme to grow into a language that can support production quality code across implementations, the Scheme standard itself must address these issues of programming in the large - i.e., how are complex applications structured in a portable manner. This should include mechanisms to specify and validate interface characteristics (requirements) between application components in a portable manner. In the past, the Scheme standard has focused on programming in the small - i.e. the language elements needed to specify the data and algorithms in a flexible manner. While necessary, these are not sufficient to allow Scheme to grow into a production quality language.
I am a professor in the astronomy department of a research university. I use Scheme almost daily in my research and teaching. However, pure R5RS Scheme is inadequate for many problems, both large and small, especially in my research. For example, it is difficult for compilers to generate efficient code for inexact arithmetic since they cannot rely on the bindings of the arithmetic procedures, there are no means to access binary data in files or in memory, and I cannot write the name of my university as a string, as ASCII has no accents. I end up either using extensions to the R5RS or writing chunks of code in C and accessing them as foreign procedures. Neither of these approaches are portable and the second is extremely unpleasant. I would like to see Scheme develop in a way that makes it easier for me to use it for solving a greater range of problems without losing the ability to write quick hacks. I am not saying that I want Fortran or Java with a REPL and first-class continuations, but I would like the next Scheme standard to allow me to write less C and more standard Scheme.
I'm a programmer who's fairly new to Scheme. To me, the most important proposed changes in R6RS are the standard module system and the standard libraries. The core language in R5RS is great, but the decision to use it always seems to create extra work because of missing libraries. There are extensions for most of the basic things that usually come with a language (sorting, hash tables, modules, etc.) but the fact that they are nonstandard creates extra work of its own as far as compatibility and portability. I haven't looked at every detail of the module system and libraries, but they look a lot better than nothing. One thing I'm not enthusiastic about in the current draft is the fact that the built-in procedures are still not polymorphic. For example, having a single procedure called 'sort' that checks the type of the argument to be sorted is perfectly possible. It might be a little faster to have a separate 'list-sort' and 'vector-sort,' but I don't think it's worth it. I also think there's no real benefit to explicitly stating the type when you sort it. When you're creating or using it, maybe, but not when you're sorting it.
I have been using Scheme for about 15 years. After going through several programming languages, Scheme was the one that immediately caught my eye in its aesthetics -- both of code, and of its design. I have been a TA in various SICP-based courses (in Ben-Gurion University in Israel, in Cornell University in New York, and also in a startup company), and most of my hacking has been in Scheme. My first well-known Scheme project was Swindle -- developed for Cornell's CS212 course (previously used a buggy Dylan implementation). The project started as a practical implementation of the Common Lisp Object System (based on Tiny CLOS from Xerox), and grew to provide more Common-Lisp-like functionality. It was used in CS212 for several years. Throughout the years I hacked together a number of projects at various sizes, mostly as a free-time hobby. After finishing my PhD, I moved to the Boston area, and joined the Northeastern part of the PLT team. With that I could finally get to make my living writing Scheme. (Something that is not easy to come by.) In practically every aspect of my involvement with Scheme it was clear that as good as it may be, it suffers from major limitations. Over and over again I had to justify Scheme in class, convince people that Scheme is a practical solution. IMO, the Scheme world suffers from the reputation of being a (mostly pedagogical) toy -- a language whose proponents take pride in an extremely short definition, even when it is painfully clear that this makes real-world code impractical. The result is a fragmented community with different factions relying on practical features found in different implementations, and too much of wasted efforts by good programmers. "Scheme" as a language suffered loss after loss to many inferior languages (shell scripts, miscellaneous extension languages, TCL, Perl, JavaScript, Python, and many more). A few projects that have been using Scheme would suffer the same problems, some died (SCWM), some switched their focus away from Scheme (Gimp). All of this pushes "Scheme" to being an abstract concept -- a generic name for a family of similar implementation-defined languages. I see the R6RS effort as a step in the right direction. A more practical definition and a module system would allow more practical code to be written and shared, making Scheme stronger.
I started programming in BASIC in sixth grade. In high school I moved on to C++ and Java, but I found the limitations and seemingly arbitrary restrictions frustrating. Senior year I found Paul Graham's essays and immediately became enraptured by the tantalizing promise of the simplicity and flexibility of the Lisp language, so I set out to learn what it was all about. I took a copy of SICP out from the library and began reading it. Initially I was turned off by the prefix notation and the seeming lack of iteration built into the language, but I quickly realized the power behind the simplicity of the language. Freshmen year I was delighted to discover that my introductory course was taught in Scheme, and while various classes since then have required other programming languages for assignments, my own work is always done in Scheme. I'm very interested in being involved in the future of the language, and I hope that R6RS should pave the way to greater Scheme adoption and interoperability.
I am a Schemer! Ein ich Schemer! Yo soy un Schemer! Programming languages that have a standard tend to be successful. A standard allows for code developed using standard features on different implementation platforms to be executed on all the platforms. Furthermore, it allows reserachers to develop new tools without having to worry about many platform-specific nuances. Finally, it allows educators to teach knowing that the standard features employed will be found by students in the implementation of their choice. As a researcher in the implementation of functional languages and as an educator that uses Scheme at all levels of the undergraduate curriculum, I feel that it is important for Scheme to have a definition that all its user communities can refer to and can use as a basis for its evolution. A standard provides a context through which we can all communicate and move forward.
As an Assistant Professor in Computer Science, my interest in the Scheme programming language originates from both teaching and research. First, I am in charge of lectures of functional programming for undergraduate and graduate students. In the first case---for undergraduate students---the lecture aims to introduce scientific students to a programming close to Mathematics, and I wrote a coursebook in French about this approach. In the second case---for graduate students---I aim to illustrate advanced features of functional programming such as delayed evaluation, continuations, macros. Scheme is the support language of these two lectures. Second, I am developing a bibliography processor that aims to replace BibTeX, the bibliography processor usually associated with the LaTeX word processor. This program, MlBibTeX for `MultiLingual BibTeX', is written using Scheme, it is R5RS-compliant and uses some definitions given by SRFIs. After some confidential diffusion whose result is encouraging, MlBibTeX is about to be publicly available. So I am interested in the future of Scheme in order to be fully able to improve this program for future versions.
I am interested in a widely accepted Scheme standard for several reasons:
1: Scheme is a very good tutorial language for:
1a: learning programming:
simple syntax,
no unexpected or hard to swallow semantical restrictions,
not prone to bugs,
a mathematically sound number system,
good tools for data abstraction,
avoids the beginning student from thinking in terms of machine
representations,
many Scheme implementations provide very good syntactical analysis
and debugging facilities.
1b: learning about programming techniques, paradigmas and so on (there is
an abundance of good text books using scheme for this purpose)
2: Scheme is a very good and flexible language for fast prototyping of:
2a: algorithms.
2b: languages and language extensions.
2c: for trying and comparing different approaches of language features
(for example my individual interest in the comparison of different
treatments of side effects in lazy interpreters)
3: Some languages feel like a set of restrictions rather than a comprehensive
tool, especially when it is clear that an implementation employs constructs that
at the same time seem to be denied to the user of the language. Scheme makes me
feel that I am given the full power of all tools used by the implementors
themselves.
I have been using Scheme for more than 10 years and around 100,000 lines of code. I always tried to ensure portability by running my code in around 10 different Scheme implementations. Unfortunately, this was not always easy. But I never regretted not to rely on non-portable extensions of one of the major implementations. A second issue important for my applications is efficiency. So, I expect better support for efficiency and portability from R6RS. For efficiency purposes, the standard should not require any behavior which puts a large difference in runtime between say C and Scheme. For portability, I hope that the standard libraries will help real-world programmers a little more than R5RS did. And finally, it is important to have R6RS and the most important (and most popular) SRFIs to live together, maybe after some phase of adaptation. The authors of these SRFIs should be encouraged to adapt their SRFIs to R6Rs. Even with more standardized features, the community efforts like the SRFI process and some portable package collections like SNOW are not to be neglected. My main concern with R6RS is that it could further split the community instead of helping to create synergies of the major subcommunities like Bigloo, Chicken, Gambit, Gauche, and PLT.
I like to write programs in Scheme, to the extent that I have implemented Scheme several times to make it easier for me to do so (T, Pseudoscheme, Scheme 48). I have helped with previous agreement-building efforts (R2RS, R3RS) because I like for other people to use Scheme, so that I can use and learn from their work and so that they can appreciate mine. I use Scheme daily in my work and have invested a significant part of my career in helping it to succeed. As a Perlisian 'ball of mud' Scheme lends itself to extension and experimentation. Scheme's boundaries have always been aggressively sloppy. Scheme's emphasis on programming for communication, as opposed to execution, is almost unique and has had, I think, a positive effect on its culture. Although Scheme has been used as an engineering tool, engineering goals such as portability, security, and efficiency have on principle never been embraced in the past. They factor into the design, and they influence implementations, but they have always played second fiddle to ease of reading, writing, and remembering. Although successive Scheme reports have made the language increasingly complicated and have included many decisions that are not to my taste, I have embraced the reports in order to help develop a community around the language. Compromises are always necessary in standardization efforts. I would just like to make sure that Scheme's message to the world, that what we somewhat misleadingly call 'programming' can be considered an intellectual endeavor that can carry the best of scientific and criticial thought, can be retained as it grows. To relegate Scheme to the service of transient engineering concerns and accidents of current software practice would be tragic, as its unusual philosophy is what distinguishes it from its many imitators.
I have encountered the Scheme language twice in my life. First as an undergraduate student, and then as a graduate student. I am now involved in doing some research dealing with languages semantics and I highly rely on Scheme to experiment new concepts. I think that Scheme's semantics and standard are not perfect yet, and that it deserves major involvement for gurus as well as newcomers, in order to improve the whole language. I reckon that well defined semantics as well as eager for comments about the language are necessary to attract new researchers and programmers. Moreover, the simple yet powerful design of Scheme makes it a tool of choice for research, provided all implementations agree on well defined foundations. As a user of one (or two) specific implementations, I think that I have a personnal idea of Scheme that deserves being shared with others and compared for the best of all of us. As a now daily (and most of the time happy) user of Scheme, I feel the urge to get involved in the evolution of the Scheme language. Long live Scheme !
I teach courses in computer science at a small liberal-arts
college. We use Scheme in our introductory course because its simplicity
and expressiveness enable our students to understand some of the key ideas
of computer science -- notably recursion, procedural abstraction, and
data abstraction -- quickly and accurately, without the encumbrances of
fragile syntax and quirky semantics. We also use Scheme in more advanced
courses (such as our courses on programming languages, algorithms, automata
theory, and computational linguistics), particularly for small,
specialized examples and demonstrations. My interest in the R6RS standard
is to keep the core language small, simple, expressive, and accessible to
novice programmers, while accommodating, through the development of
libraries, the vast increase in the effective range and usability of Scheme
during the fifteen years since the publication of R5RS.
I am also working on a small textbook on algorithms in which the
code examples are presented in a purely functional subset of Scheme. This
work gives me an additional interest in R6RS: I'd like to be able to use
standard library mechanisms to control the subset explicitly.
I am interested in Scheme for three primary reasons. First, as a programmer Scheme is the primary language I use to create programs both large and small. Therefore, the advancement of Scheme and the greater portability offered by improvements to the Scheme standard are of great use to me. Second, as a programming language researcher, Scheme represents an important tradition in the design of programming languages, and one the should be continued, with innovations in the relevant areas such as continuations, macros and module systems. Finally, I am the designer of Typed Scheme, a statically typed dialect of Scheme. I am therefore interested in the continued success of Scheme as a substrate for Typed Scheme, and as a complementary language, since Typed Scheme allows for the integration between statically typed and dynamically typed Scheme code. Typed Scheme also utilizes advanced module and macro system features to function as a layer on top of Scheme, some of which are under consideration for R6RS.
I am a graduate student, and the focus of my research is the Scheme macro system. My goal is to make it easier for programmers to understand Scheme's hygienic macro system and to write clear, robust macros. To the first end, I have created a stepping debugger for Scheme macros as a tool that runs within DrScheme, a popular Scheme programming environment. To the second, I am investigating alternative notations for defining macros. To me, the defining characteristic of Scheme is its powerful hygienic macro systems. Other languages may be lightweight implementations of "the lambda calculus plus useful features." Scheme is unsurpassed, however, in its support for extending the language with new syntactic forms with a minimum of fuss. Particular Scheme implementations have pushed macros far beyond the capabilities described in R5RS. The Scheme standard should not fall too far behind the state of the art in this area.
Scheme is a functional language with a simple syntax and with all the features one could want in a functional programming language. It was the first functional programming language I ever learnt and I enjoy coding in it a lot. If the standardization that will gradually begin to occur by publishing R6RS will produce the uniformity that C, Java, and Haskell have, then I am all in favor of it. The simplicity of Scheme makes it very suitable for teaching. I am interested in one day teaching Computer Science and so I would like for the language not to stagnate, but to continuously improve and become an even better teaching and programming language. Finally, my aesthetic preferences lie with simplicity. In agreement with the quote in the voter registration ticket, I must say, Scheme does efficiently do what many other languages achieve via horrid syntax and complicated semantics. If Scheme were to die off (by way of first stagnating), the whole world--and I in particular--would lose a beautiful beautiful language.
I want useful language. All features of Scheme language help it to be useful. Small is one side of been useful. Programmable is another side. Expressive is yet another side. But something is still missing. Core language makes an impression that it is useful only for logical puzzles and math tasks. Scheme is small language, but it should be useful for writing large programs. Scheme too much interpretation-oriented, it should grow to allow independent development, compilation and packaging. I like Scheme not for blind minimalism, but for orthogonal approach to features. Scheme should include features which are orthogonal to existing features, which are found useful by language users, which included in several implementations. Wheel is basic, and should not be re-invented. Scheme minimalism allowes implementors to experiment with new features, but some of those features are already mature and known to be required by users. We need next standard, so bigger range of programs whould be portable accross implementations.
I have been a Scheme programmer for the past 15 years now, and for the past 6 years as a professional programmer. My PhD thesis was about the optimization of multi-module Scheme programs. I am also the author of some popular Scheme libraries and tools, like lalr-scm (a portable parser generator) and SchemeScript (a Scheme environment for the Eclipse platform), and I blog regularly about Scheme (theschemeway.blogspot.com). Finally, I am the main organizer of the Montreal Scheme/Lisp User Group since 2003 and I push hard for the use of Scheme in the industry. I strongly believe that Scheme has an important role to play both in academia and the industry. It has influenced many other programming languages in the past and will certainly continue to do so in the future. It also has an important role to play in the Computer Science curriculum. I am very much interested in results of the R6RS ratification process as this will definitely impact my daily use of Scheme in industrial settings.
As a student of programming languages and a Scheme user for the last five years, I often use Scheme for both research and programming. That last statement is a bit too generous, for I’ve used PLT Scheme exclusively. R5RS was a great little language for exploring algorithms and simple syntactic forms. But, it was far too little to be useful in any way. I could keep up my past trend of ignoring the Scheme standard, but I’ve noticed that R6RS is taking steps to address many of the inadequacies of R5RS that affected me. It is in my interest as a programmer and a researcher for there to be a Scheme standard that allows me to write large-scale programs, and I feel that R6RS is taking steps in this direction. Therefore, I have a stake in ratifying (or not ratifying) R6RS, as it will affect Scheme implementations of the future, including those that I use on an everyday basis.
I am a part-time instructor at UMass/Boston (with the working title of Industry Professor of Computer Science). One course I teach frequently is cs450, which is mainly based on the Abelson-Sussman-Sussman SICP book. Partly as a result of teaching this course, and partly as a result of my own work in CS research and compiler design, I am impressed and interested in styles of functional programming and in Scheme in particular. Scheme seems to me to be distinguished from other functional languages in its fundamentally bare-bones approach. The language contains a relatively small set of powerful primitives that can be used to model features found in different languages, and different styles of programming. This makes Scheme a wonderful choice for an undergraduate course in what would be called comparative linguistics in the humanities departments. I hope to see this aspect of Scheme preserved; it has been very useful to me and to my students.
I am interested in R6RS because at Beckman Coulter we have used Scheme for the past decade and hope to continue doing so for another decade. We have used Scheme for product development, testing, and research. We love the flexibility that Scheme gives us to try out new ideas. Scheme itself is very simple and doesn't change very often, which helps us become very proficient using it. Because it provides good procedural and syntactic abstraction, we can tailor our code to the task at hand. Its handling of tail calls and continuations are a breath of fresh air compared to the fixed-size, single-segment stack model popular today. I was introduced to Scheme while a student at Rose-Hulman Institute of Technology, but I did not come to understand its utility until I went to Indiana University for graduate school. Kent Dybvig, Dan Friedman, and others taught me how Scheme is well suited as a meta programming language for experimenting with lots of different ideas ranging from digital hardware design to high-level programming language constructs. In 1997 I started working for Beckman Instruments, now Beckman Coulter. My first task was to design a new scheduler for automating assays used in drug discovery laboratories. Customers use our SAMI(R) software to describe the experiments they would like to run using a graphical flow chart language. Our software then schedules and coordinates the operations of the robot, pipettors, readers, and other devices to perform the experiments efficiently. The previous scheduler was written in C++ and had a few bugs that customers had encountered. Even though my manager was unfamiliar with Scheme, he allowed me to write the new scheduler in Scheme. He was very pleased that I developed a prototype quickly, thanks in large part to Scheme's automatic storage management system, continuation support, and extensible syntax facility. These language features help me build powerful abstractions that are impedance matched with the problem. In 1998 we released SAMI 2.0 with 15,553 lines of Chez Scheme code. Customers were pleased with the product, and it proved to be very stable. Subsequently we developed a COM interface to Chez Scheme and have used it over the years to provide an easy way to interoperate with other programming languages. In 2002 we undertook an ambitious project to rewrite SAMI to provide greater flexibility for systems with multiple robots. In October 2004 we released SAMI 4.0 with 103,614 lines of Chez Scheme code and 214,208 lines of C# code. The Scheme code employs multi-paradigm programming. It uses continuations to perform non-blind backtracking, the macro system to emulate a simplified version of C#'s object system, and one-shot continuations to provide Erlang-style message passing among light-weight processes for robust asynchronous communication with the various devices. A colleague of mine used Chez Scheme to develop an instant messaging server using message-passing style that has been extremely robust for the approximately 130 users across Beckman Coulter's internal network. We plan to use Scheme in future products. A project to develop a new molecular diagnostic device and another pproject to develop a data manager for hospital laboratories will both likely use Scheme because of its flexibility and robustness in multi-paradigm programming.
Scheme is a leading representative of a clean language for algorithms. I have an interest in Scheme as used in education and practice. The upcoming standard will strongly establish Scheme as a preeminent language for both teaching and practical programming. One of the deficiencies in the current standard, the lack of a specified module standard, is crucial for programming in-the-large. It is important enough that each substantial implementation of Scheme has reimplemented their own system for linking modules together. This reinvention unnecessarily splinters the community. Other additional features specified in R6RS, such as records/structures are features that every realistic program uses. A substantial Scheme program should be portable, but as it stands now, most substantial Scheme programs are tailored toward a specific implementation. I would like to see Scheme more widely accepted in the larger programming community, and I see the new standard as a step toward wider acceptance and adoption.
(1) I am the founder of PLT, and co-inspire its direction with Matthew Flatt and Robby Findler. (2) I am an author of three Scheme-based books, two of which use a subset of standard Scheme. (3) Finally, I am a programming language researcher who has published a large number of papers inspired by and based on Scheme. (4) A such, I would love for the Scheme report to set the bar as high as possible for academic languages so that researchers and authors can cite an exemplary chain of evolution of language definitions. -- I must say I find it embarrassing that we do not use web forms, powered by a Scheme server, for this process. -- Alan Bawden has politely and in a scripted manner asked me to supply additional words to satisfy the 150 word limit and additional evidence. For the former, see the end of this write-up; for the latter, take a look at the papers at "http://www.ccs.neu.edu/ scheme/pubs/", most of which I authored or co-authored.
Scheme is important to me because I think it is the best programming language. It comes close to the programming language which I would like to use for all my programming. What I like about Scheme are its regularity, flexibility, and safety. What I do not like are things like the abbreviations, legacy names, double pairs of parentheses, permissiveness, etc. Fortunately the language is so flexible that most of it can easily be adapted. So I made my own version of Scheme on top of Scheme. Consequently, my interest in the Scheme standard is that I depend on it for my own version. If Scheme improves then that makes it easier for me to use, maintain, and improve my own version. What I like in particular about the new proposed standard is that it makes the language more complete and that it becomes really easy to rename and exclude things.
Even having gone through a masters program in computer science in the early 1990's, I had never used Scheme until retirement from medicine. I was doing a survey of the new languages of the time, and had the great fortune of coming across TPSL 3rd ed. I ended up selecting DrScheme as my implementation of choice, and have been increasingly more active in the Scheme community ever since. Scheme is a very personnel subject for me, as I have no commercial interest tied to it, and yet I spend the great majority of my day writing Scheme code, and publishing blog articles on the subject of Scheme. I derive a great deal of enjoyment and edification out of being a member of such an intellectually stimulating group of people as are those that make up the active Scheme community. In addition, beyond what Scheme means for me personally, the language itself provides, for those who would choose to study it, a mechanism of expression and extensibility that makes it particularly well suited for use as a mechanism for discourse about languages in general. Scheme has been the birth place of many of the most intriguing notions of what a language can provide, beyond simply being Turing complete in its expressive power. I would hate to think that I could not pass on to my child what I have learned from Scheme, because, for lack of a standard, it had faded from use in the academic and commercial communities. The R6RS process is of great interest to me because my belief is that the current state of affairs, in which each vendor is coming up with their own mechanism for packaging code into a reusable, in some cases dynamically linkable, module is fracturing the Scheme community needlessly by a person's choice of implementation. While I think there is room for healthy competition and innovation among vendors, I strongly believe that it would be a win-win situation for all vendors to share a common method of packaging code for reuse. From what I have read in the draft, I believe that the committee has produced a model that should be easy enough for all vendors to adopt, that the module system proposed by the draft will gain wide spread support, and the Scheme community will finally have, what most successful languages of our time have, a common format for distributing code. On the other hand, if we fail to come to consensus on such a mechanism, I fear that there are a far too many languages vying for adoption, and in many cases emulating the features of Scheme that make is so great, that we risk loosing the language, only to have it replaced by the likes of f#, developed by monolithic corporations that will not bother to hold a vote on what the language should or should not become. I view R6RS as one of the great turning points for Scheme, whose failure of adoption may lead to the loss of a truly beautiful language.
I've been an avid fan of Scheme since 1984, when I first used it as part of the 6.001 Structure and Interpretation of Computer Programs course at MIT. It has been my favorite programming language since then, and while I rarely use it at work, I use it for all my programming projects at home. While I was an undergraduate, a staff member, and a graduate student at MIT, I spent many years working on MIT Scheme, including its interpreter, compiler, runtime system, debugger, and editor, and I continue to make small contributions in my spare time. I've also spent a lot of time working on my own unfinished implementation of Scheme. I followed the R4RS and R5RS standardization processes closely, participated some in the IEEE Scheme standardization process, and have participated quite a bit by email in the R6RS process. I want to help make sure that R6RS maintains the right balance between the diamond-like jewel Scheme has always been and the practical everyday programming language that we have always wanted Scheme to be.
I'm a user and contributor of Chicken Scheme. I have extensively used Standard ML and Scheme to construct domain-specific languages and code generators for numerical simulation of neuron models. I ended up settling on Scheme as my primary programming environment for creating and controlling numerical simulation experiments, because there were so many competing high-quality compilers and interpreters for Scheme, unlike other high-level languages used in scientific modeling, and because Chicken Scheme already had many convenient libraries available. Something that is said often is that one of the reasons that we have so many good compilers for Scheme is the minimal design of the language. This makes it easy to write compilers and to experiment with language features without spending much effort figuring out how to incorporate each feature in a massive design. For example, the author of Chicken Scheme recently created a mini-compiler for a restricted subset of Scheme that generates static C++ code, which is extremely useful for many problems in numerical simulation design, where garbage collection is undesirable, and performance is of utmost importance. And thanks to the minimal design of Scheme, Chicken also provides an excellent and very flexible foreign-function interface. The combination of this foreign-function interface and the static mini-compiler has allowed me to design a simulation system, implemented entirely in Chicken Scheme, that incorporates high-performance modules, written in the restricted static subset of the language, that are controlled by a flexible high-level language and a scripting interpreter on top of that, and this is a sort of the holy grail of high-performance scientific computing. So it is this minimalism and freedom to tinker and experiment with the low-level machinery of the language that is particularly important to me. There is also another dimension to this: nowadays, scientific computing utilizes various kinds of exotic hardware, such as FPGAs, GPUs, embedded processors and DSPs. A large and complicated language design would make it very difficult to write code generators for such special-purpose hardware, whereas Scheme seems to be ideally suited for such experimental work. R6RS seems to attempt to push Scheme in the direction of widely-used interpreted languages such as Python and Perl, and to provide an all-encompassing standard. I do believe that Scheme currently has a unique and important role, and should not attempt to become another Python or Perl. While it is true that the current standard suffers from a lack of portability across implementations, I think it is very important to maintain and nurture the vast ecosystem of Scheme implementations, and not make it difficult to have multiple competing compilers and interpreters.
The niche Scheme currently dominates is: language so simple its basics can be learned in an hour and an interpreter written in a page or two, but so powerful it is the lingua-franca of programming language theory. In other words, the minimal features that need to be added to an eager lambda calculus with side effects to allow convenient creation of data structures and of fun. Dominating this niche means Scheme is great for teaching, and for prototyping new language features and implementation technologies. I have been using Scheme for these purposes for quite some time: I developed a course at UNM/CS which taught Scheme at a sophomore level, and in my own research I use Scheme as a testbed for new language technologies, e.g., object systems with first-class classes (Oaklisp, some time ago) and more recently first-class automatic differentiation operators. To protect Scheme's dominance of these niches, I believe that we should preserve a small language optimized for elegance and simplicity and rapid teaching and rapid implementation. And I believe we should be wary of premature optimization and of piling feature upon feature to address perceived deficiencies.
Scheme is my favorite programming language, and I consider it as near-perfect. Due to the conciseness of R5RS, Scheme interpreters and compilers have sprung up for a variety of environments: today we are fortunate enough to be able to use Scheme to create executable applications, Java applications (including web applications running on top of J2EE), to script OCaml programs, and even to write AJAX applications via Javascript translation. Moreover, we are able use more or less the same code across these various Schemes, as R5RS compliance is common and various extensions to the language and libraries have been standardized into SRFI's. Due to the arrival of this golden era in Scheme's evolution (and more generally the history of programming languages), I've been able to use Scheme for most of my endeavors, from web applications to file systems to shell scripting to numerical applications. It's been an extremely pleasant experience, and I've been able to build a Scheme code base that I can reuse in new projects with little effort and extraordinary productivity gains. My interest in R6RS standardization is to make sure that Scheme's advantages are not lost, and new and useful features are added to the language conservatively. In other words, programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
Computer Science: My sole interest is in languages, the paradigms they enable, encourage or discourage (e.g. functional programming), and since reading the "lambda: the ultimate ..." papers in 1980-1 Scheme has been my vehicle for that. Education: The above interest extends to education: I've watched the evolution of SICP from draft form, and am now watching the evisceration *in this area* of the MIT CS required curriculum with horror. Recreation: By temperament I'm a scientist (chemist), and while programming and software engineering are fascinating, developing software was mostly a means to an end. Circumstances and aptitude forced my career to be in software development, so when I program for myself, 'for fun', I want it to BE fun. That means LISP and most especially Scheme. Projects: I am now essentially retired, and I plan on spending a fair amount of time doing useful FOSS work. That which is not forced to be in C I will do in Scheme. A good R6RS standard will further all of my above interests and goals.
I am a designer and programmer that works in both the academic and business fields. I utilize scheme almost entirely for the majority of my work, and it is my intention to continue to use Scheme in these capacities. Up until now Scheme has been missing a few nice features which prevent the easy dissemination of nice and portable works, and when teaching, the support of multiple Scheme implementations is somewhat annoying when they are largely different. However, as a business programmer, I also have to be able to provide for special cases and unique processes, so the manner in which various problems in the Scheme language are rectified is of concern to me. I hope to be able to weigh in on a decision that will likely result in a significant impact on the Scheme community as a whole. I also have money invested in Scheme implementations, and I desire to Scheme move in a productive and principled manner.
Scheme is the language I've been programming in since the fifth grade (1991). I am substantially invested in a number of ways, including a large existing codebase. I continue to use Scheme for my functional programming rather than Haskell or ML because of three major benefits I derive from it: syntactic extension, ease of manipulating code as data, and the conciseness of data represented in S-expression form. That said, the single bigest failure of Scheme in my view is the balkanization of implementations. Writing significant applications portably is nearly impossible, and the community has failed to build a large collection of shared libraries. I think the minimality of the R5RS standard is largely to blame. R6RS will provide a more complete and usable language standard. Thus I believe it is critical that R6RS be ratified and subsequently adopted by several of the major implementations. I see this as such an overwhelming imperative that I believe it dwarfs the importance of the actual design particulars that tend to inspire bickering.
I am a single developer within the Network Services division of IBM. I currently use the Scheme programming language to develop internal solutions, mainly for tasks that were previously addressed with Perl. The language choice of Scheme is primarily due to its simplicity and powerful means of combination. Programming in a functional style promotes reusability while reducing the complexity of language constructs, especially when compared with mainstream object-oriented languages. When used in this way, Scheme programs can be written in a very declarative fashion, which increases productivity and allows for highly readable programs. I am interested in the outcome of a new standard for Scheme primarily because I enjoy writing Scheme programs, which would influence the capacity in which I use it professionally. I feel that a community-involved, active, light-weight standardization process is a great asset to the Scheme community, and I wish to participate in the ratification process.
Scheme is one of the few programming languages that I've come to actually enjoy using. I value it, above all else, for its simplicity. At Parsons School of Design, I've introduced fellow students to programming via Scheme and the tremendously well-written book, "How to Design Programs". The combination of a simple language, great texts, and implementations that consider the beginner (namely PLT) make for a great combination. In my own work, I've used Scheme to implement prototypes for two programming languages. I've also used it for music composition via Rohan Drape's excellent Supercollider client, "rsc". When one is producing music programatically, a language that works with the programmer and doesn't irritate is more critical than ever given the detrimental effects that distraction has on the process. My interest in the standard is to do what I can, in my limited capacity, to ensure that my programming language of choice will continue to be optimally useful for teaching, language design, and my artistic pursuits.
From the first day of my experiences with scheme, I liked the elegance which comes out of it's simplicity. This first contact with scheme took place in Mike Sperber's introductory courses at Tübingen University, where we used DrScheme to learn how to solve the first problems with computer programs. Actually, the work with DrScheme was so simple, that many of my colleagues already stamped scheme as a toying language, with which no serious work could be done. But the other ones, including me, later had the chance to do various interesting stuff with Scheme 48 and Scsh. Personally, I participated in implementing an X window manager, a generational garbage collector, and as my diploma thesis, a transparent way to utilize multiple processors with a Scheme 48 program. Now that I work in the industry, I see big chances for scheme as an embedded extension and customization language for bigger software systems. Schemes flexibility could help in reusing code written in existing customization languages, and it's simplicity imposes a small learning barrier for it's users. Therefore, I'm interested in the future development of the language scheme, and would like to take part in the ratification of the R6RS.
I am a developer who has been working with and enjoying Scheme for a few years. I feel that Scheme occupies an important niche in the programming-language ecosystem, that is, as a language in which it is easy to program and just as easy to think about programming. This simplicity comes from a compact, orthogonal core of ideas upon which more complex constructs can be built. There have emerged a number of languages, such as Tcl, Perl, Python, and Ruby, whose evolution is shaped by local pragmatics and whose semantics are frequently standardized by a single implementation. Scheme does not exist in the same part of the programming-language spectrum with these languages, nor should it; it is a core abstraction, a starting point for programmers and language implementors to explore and experiment. My interest in the Scheme standardization process is therefore in helping to preserve Scheme's place as a clean language to think in and build on, as well as a practical tool to program with.
I am interested in Scheme as programmer and as a researcher. As a programmer, I maintain DrScheme, PLT Redex, and some other PLT-based software. I expect DrScheme to support future revisions of Scheme, including R6RS, and I expect the others to be written in standards-conformant Scheme. So, I'm interested to see what language I will be programming in and supporting. I also write research papers that are based on (models of) Scheme. Such models should follow the spirit of Scheme and the RnRS series is the definitive source of that spirit. So, I'm interested in the latest RnRS to see how such models might have to change, in order to capture the essence of Scheme. Finally, I am interested in the discussion surrounding the ratification of the draft of R6RS. The face of the Scheme community is emerging and I find that fascinating. So, the actual vote will help me to understand which group is the vocal minority and which group actually captures the spirit of the community, at least wrt the draft R6RS.
While I am neither a Scheme implementor nor a heavy Scheme user, I have followed the development of the Lisp family of languages since 1972 with great interest, and have implemented a Lisp or two, mostly for the challenge of it. My particular interest in the R6RS process is in bringing Scheme up-to-date with Unicode, and I have been a major contributor of R6RS comments on that subject. R6RS is certainly not perfect, but it is the first Scheme standard that shows serious concern for portability. Although it is possible under earlier standards to implement everything oneself in a small core dialect, the result is a proliferation of pointlessly incompatible implementations of the same concepts under the same or slightly different names. R6RS in combination with existing and novel SRFIs goes a long way to alleviate that issue. I am now also a participant in the Chicken Scheme community (specifically, I am the chief Cygwin tester for Chicken), which as a whole tends to be rather anti-R6RS, and I hope to do something to help change that, partly by helping to make R6RS the best standard possible.
I am the sole author of Stalin (a high-performance implementation of R4RS) and Stalingrad (a high-performance implementation of a functional, numeric subset of R4RS that adds first-class automatic differentiation). I conduct research in both programming languages & compilers and AI (including computer vision, computational linguistics, robotics, machine learning, and cognitive science). All of my publications since 1981 are supported by substantive implementations, all of which are in Lisp or Scheme. All of this code has been publicly released and some of it is widely used. Every course that I have ever taught (including AI, computer vision, computational linguistics, and programming languages since 1993) has been based solely on Lisp or Scheme. I currently teach AI every semester in a course whose material I have solely prepared and which is based solely on Scheme. I have shared the material that I have prepared for the courses I teach with other teachers, including the course software that I have prepared, all of which is written in Lisp or Scheme. Overall, several hundred students have taken my courses.
For the last 5 years I've been using Scheme extensively. I have done my Master's on adapting Scheme to concurrent programming, and I've used it for other research. I've also had the chance to use it to teach practical aspects of programming languages. I have worked both as an employee and as a paid consultant to develop and maintain Scheme programs. I also plan to use Scheme in future projects. The strength of Scheme lies in its simplicity and its dynamism. It is why Scheme in its current form is a good teaching, research and development programming language. It is good for teaching because it is simple. It is an effective research vehicle because of its flexibility: it is easy to to adapt to any situation, either at the language level or at the implementation level. Its dynamism provide powerful support for developing and maintaining applications. I want to vote in order to express my opinion on whether the current proposal for R6RS preserve those aspects of the language and respect the spirit of Scheme.
I have been a long time user of Scheme as well as an implementer of a couple of experimental Scheme interpreters (never released publicly). I have used Scheme for personal and paid work, things like code for a network processor, testing code for ASICs, for generating code as well as for prototyping programs & modelling algorithms. And, of course, as a swiss-army tool for all sorts of tasks including systems programming. As an implementer I am concerned about ease of implementation, size of the language, completeness and orthogonality, etc. As a user I am concerned about ease of use, efficiency, portability across implementations and so on. If the standard is not embraced by authors of the implementations I routinely use, I would be forced to use a subset they implement. As an experimenter I am concerned about the size and simplicity of the language as a complex implementation is harder to experiment with. I have been following the srfi-* mailing lists and the r6rs list. I tend not to argue much in public forums or send "me too" messages but I have been following the progress of r6rs with avid interest.
I am a doctoral student in language theory. Scheme is the language I program in most often. I have been programming in Scheme for years, and, in addition, I have worked on implementing the Scheme system Scsh. I have worked with Scsh, Scheme 48, and MzScheme; all three are R5RS-compliant, yet there are significant differences between them that make it essentially impossible to write portable programs. My thesis work includes a compiler that I intend to someday extend to a standards-compliant Scheme implementation. My thesis work involves language implementation via hygenic macros, similar to those found in Scheme. Language extension via macro is an enormously power feature, and has the potential to be extremely compelling to a wide audience; Scheme is adaptable to a surprising variety of problem domains, thanks to this one easily-used feature. However, in order for this feature to be seen by a wider audience, the community must show progress, which at this point means a new (and hopefully more complete) standard.
Scheme puts me in an ironic but not-too-uncommon predicament. The language itself is by far the best programming language I know. Unfortunately, the periphery around the language --- libraries, documentation, tutorials, a sense of united community --- leaves a great deal to be desired. So I am stuck: Do I use and endorse an inferior language with fuller libraries and more clearly organized documentation, or do I use and endorse a superior language in which I must write every other library function I wish for because it either isn't there or I can't find it? The Scheme evolution process gives me a way out: if, after perhaps some years of work, Scheme gains the preiphery I wish for, I will be satisfied, and perhaps the world will be a little better off. Lest I be misunderstood, I will raise the dichotomoy between Scheme itself and "Scheme Implementation X". I have not studied all the implementations as carefully as perhaps I should have, and it is quite possible that some individual implementations of Scheme are rich in libraries, well documented, and have united communities. The larger Scheme community, however, has not, to my knowledge, picked one of those as the unequivocal winner. Scheme as a whole remains, therefore, divided, ill supplied with libraries, and open to improvement. That being said, it is my opionion that the multitude of Scheme implementations can be a source of great strength for Scheme, which is why I am interested in the Scheme standardization process rather than in merely seeking out or creating that one ideal implementation.
Scheme is a very advanced and flexible programming language that I use whenever possible. It is clean and can be used by the programmer to develop the programming language he needs while writing the code he needs. This aspect of extending the language itself on the fly enhances re-usability without introducing unnecessary clutter known from languages that force the programmer to treat everything as an object. Scheme takes another approach: Instead of treating everything as an object, so you can pass it to a function, it allows you to pass anything you like to a function. However, Scheme also has some disadvantages: First, code is de facto very hard to understand, if it is not well-documented. As a remedy, documentation tools have been developed and are freely available. Schemers should use them more often. Second, it is mainly used in academic environments. Unless there will be substantially more final and widely implemented SRFIs, this will not change. However, I do believe that the more SRFIs become final and supported by Scheme implementations, the more popular Scheme will invariably become outside academia. Third, R5RS Scheme has lacked a number of features such as a common library structure and Unicode support that are essential for a language nowadays. To change this situation, the R6RS efforts are in my opinion a step in the right direction. There is still some essential features missing. The most important one is in my opinion some reasonably complete standards for writing graphical user interfaces and for accessing platform-dependent features, which can be implemented optionally. It is my hope that in the near future such standard specifications will be available as SRFIs and will be provided by various implementations that already provide graphical user interface libraries and foreign function interfaces. Apart from this, Scheme is already a rather complete language. And if something is missing, you just add it.
The Transterpreter is a portable virtual machine for supporting the exploration of CSP-based languages in small and large contexts, using instruction set of the Transputer (and the programming language occam) as a starting point and implementation target for our explorations. In developing tools surrounding the virtual machine (eg. a new linker, compiler wrapper, and FFI support tools), we chose to use Scheme, largely due to the open, portable, and robust nature of the PLT Scheme implementation. In a perfect world, we would not be tied to any one implementation, but without things like a common 'module' or 'library' construct, we cannot easily decompose our software in safe and sensible ways. As the primary maintainer of the Scheme portions of the Transterpreter's toolchain, I am interested in seeing progress made towards a day where the Scheme I write can (easily) run on any RnRS compliant implementation without having to sacrifice reasonable/practical language constructs.
Scheme, from its inception, has been an exercise in condensing
complex ideas to a simple set of primitives in terms of whose
abstraction and combination the complex ideas can be straightforwardly
expressed. The ideas of the core of Scheme could fit in a few pages
of description, and suffice as the basis to express a broad range of
sophisticated ideas; because of this I have been attracted to Scheme
for as long as I have been aware of it.
Scheme has been an invaluable pedagogical vehicle, because of its
economy and flexibility of underlying concepts, allowing ideas to be
expressed easily by novices without the barrier of a mountain of
syntax to memorize. I have exploited these properties of Scheme to
teach several courses using Scheme to high school students, and I have
personally tutored innumerably many other people from a wider range of
backgrounds than I can remember.
I have contributed substantially to two major Scheme
implementations, Scheme48 and MIT Scheme. I have been an active
participant in the development of a number of Scheme Requests for
Implementation, and have authored several of them as well. And nearly
all of my programming work in the past few years has been in Scheme: I
have an interest in it.
I am a director of Untyped Ltd, a UK based consulting and software development company. Much of our recent work has involved web development in PLT Scheme. We find Scheme to be an exceptional language for this purpose: features such as first class procedures, continuations, macros, and s-expressions provide power and elegance that cannot be reproduced in many mainstream web programming languages. The principle disadvantage of Scheme as a language for commercial development is its relatively small, fragmented community. At Untyped, we have had to write substantial amounts of code that we would have been able to get as third party libraries had we been using Python or Java, simply because those libraries weren't available as part of PLT. It is my belief that a wider Scheme standard, with a standard module system and standard libraries, will increase the mutual compatibility of Scheme distributions and help bring the community together. A larger community means more development, more development means more developer support, and more support makes Scheme a more compelling choice for commercial development.
Even before I considered studying programming languages formally,
I remember having been impressed by the elegance of Scheme and by
the longevity of the family of languages it is a member of.
Since then, I have become a computer science student in a
university where the first class used Scheme, which confirmed that
it was a language suitable for making general concepts of computer
science accessible to beginners. That experience also let me
contemplate the apparent universality of a simple language that
was also used in the Real World.
My fascination for programming languages led me to become a PhD
candidate, on a subject involving functional programming. Even
though I have also been attracted by statically-typed languages,
Scheme remains an extraordinarily prominent part of the functional
programming scene: its fate will no doubt affect all people
working in that field, including me.
The R6RS ratification process is certainly an important one; it
will turn Scheme, with its currently minimalist feature set, into
a language where modern, higher-level features will be available
portably; making the language useful to more people. It seems to
me that having all users and implementors agree on a standard
definition is necessary to ensure that the language will be more
easily adopted by developers and implementors alike.
I'm running a small business of writing software, and I use Scheme. Choice of programming language is one of the most important factor that affect productivity of small development farms like mine. Scheme's clean design and extensibility is indispensable for me to keep up with the business demand, since I can transform the language info an ideal form to solve the given problem, while I can trust such modification won't break because of Scheme's solid foundation. Few other languages, even much richer in features, give that kind of assurance and eventually show their limitation that drag the development. For small farms like mine, anything that drags the development can be deadly. Although R5RS plus SRFIs have been serving well for the purpose, there are yet some warts in the Report (mainly I concern some ambiguities and underspecifications, rather than the lack of features). So I welcome the new revision. At this moment I have a mixed feeling on the R6RS draft; it does fix problems I saw in R5RS, but also it specifies a lot more, which I'm not sure is necessary. Yet I appreciate all the efforts the editors put into the draft, and of steering committee and participants in the discussion list. Whatever outcome we get by this voting, I believe those efforts won't be wasted, and can be the basis of better languages and implementations in future.
As one of the original developers of Scheme, participant in earlier Revised Reports, and the author of two textbooks that use Scheme, one to communicate concepts of programming and another to communicate concepts of classical mechanics, I think that my interest in this matter is pretty obvious. In addition, I am a heavy user of Scheme. I use Scheme to build software used in classes I teach. I use Scheme in research on AI, Programming Languages, and in Physics. I have used Scheme in the design of hardware, such as the Digital Orrery and the Supercomputer Toolkit. I have used Scheme in the development of software for professional astronomical observatories: the mirror-support system for the Hiltner telescope on Kitt Peak and the guider-probe controllers for the Magellan telescopes on Las Campanas in Chile.
Scheme having been my first formally taught programming language, it remains my language of choice for most tasks. Not only is Scheme an elegant language with an academic history and a sound theoretical basis, but it is a practical language, with many implementations. This latter part, 'many implementations', is both a blessing and a curse. The changes in R6RS will help close the gap between compliant implementations: the addition of Unicode support and a standard library are absolutely necessary for Scheme to keep up with the times. Other vital additions include the exception/condition system, standardization of record types, and hashtables. These are all core structures in programming, and I need them to do my work. This has not yet answered the question why I would have an interest in the standardization of Scheme. PLT Scheme, for example, has support for all of these things. My interest is very much in portability. Last year, I wrote a program for elliptical-curve factorization. With its ease of abstraction and numeric tower, writing the program was an afternoon's work. When it ran slowly in PLT Scheme, however, I was frustrated. None of the optimizing Scheme compilers would accept my code, since it was littered with convenience functions and macros (case-lambda and records, for example). The conversion process was not trivial. With a standard library, this wouldn't have been a problem. R6RS will let me continue to write in Scheme with a guarantee that more programs will run in more implementations.
I've been using Scheme since I started my university career eight years ago. I programmed the server side scripting in the SUnet webserver where I tried to stick to the Scheme paradigm: using a small number of function to express web page delivery. I also tried to use Scheme for administrative tasks by writing small scripts in scsh. However, I failed most of the time due to various restrictions and impossibilities in Scheme (or scsh, for that matter). In particular, the current Scheme standard is not aware of any character encoding, which makes it hard to 'talk' to other programs, for example via XML files. Another problem was that although there is a single Scheme standard, I could not easily use other Scheme languages, as some of the things real-world programs use (such as hash-tables) were implemented in a library which was only available to my Scheme implementation. So, I would like to see the new Scheme standard to allow more real-world programs which can be (more) easily be ported between various Scheme implementations.
I am interested in the outcome of the process for three reasons. First, I intend to be a lifetime user of Scheme, and desire the standard to the best it can be for the selfish motive of having code written for me by others. Second, as an aspiring teacher and advocate, I have an interest in the standard being sensible to beginners and potential converts. For example, the Common Lisp standard is incomprehensible to almost everyone, and that outcome would reflect very poorly on Scheme. Third, I am a member of the PLT Scheme development group and the standard of the language will have an impact on my work. In particular, I manage the PLT Scheme web-server, which intends to offer a version of Scheme with web application capabilities. If the standard makes crazy decisions, then it will be difficult to recreate the Scheme semantics in this web-language and/or leverage the Scheme brand name.
Although I wrote my PhD thesis on the actor model of concurrent computation, which was the original inspiration for Scheme, I did not become involved with Scheme itself until Professor Dan Friedman taught me how to teach programming languages. Instead of building the course around Scheme interpreters written in Lisp, I suggested we use interpreters written in Scheme itself. To make those interpreters executable, I wrote Scheme 311 on top of Franz Lisp. I then built a much better byte code interpreter that became MacScheme. It acquired a native code compiler and grew into MacScheme+Toolsmith. During the early 1990s I wrote the Twobit compiler and supervised Lars Hansen's construction of Larceny. The Larceny family of implementations now has four back ends that generate machine code for Sparc and x86 processors, C code for most other processors, or CIL code for Microsoft's Common Language Runtime. I prepared an agenda for the 1984 workshop at Brandeis, edited the Revised Revised Report, and have contributed to every report since. I have written at least a dozen other papers related to Scheme. I am currently maintaining over 50,000 lines of portable Scheme code that run in several different implementations of Scheme.
I have participated in the design Yale Scheme (T), have been publicly and privately involved in conversations with members of the Scheme community about the design of specific Scheme-related issues (control features, error system, etc), have used Scheme professionally in the past (and might again in the future), and have invested personal time and energy as a member of the committee previously entrusted with the design of Scheme. All of these things illustrate my connection to and commitment to the Scheme language in specific. More generally, I have participated in the use, design, implementation, documentation, standardization of (and public speaking and published written commentary about) various symbolic and functional programming languages (various dialects of Lisp, Scheme, ML/Haskell) professionally for almost 30 years, I have a demonstrated interest in seeing symbolic and functional programming technology of this general kind succeed technically, socially, and commercially in order to assure its acceptance as a manner of expression in a variety of circumstances. Such circumstances might include, but are not limited to, encoding and exchanging knowledge for both academia and historical records, codifying data and processes in a form useful for commerce, exploring and visualizing concepts and methodologies in research, and general expression of less materially purposeful forms, such poetry and literature. I am sometimes critical of the Scheme language, and often prefer programming in Common Lisp, but I do not seek to make Scheme into Common Lisp--I think it serves a different user base. Moreover, I do not think a community is ill-served by constructive criticism. I find myself enriched by the study of all things, and I take it as given that unconditional allegiance is not the price of admission to this group.
I'm interested in the Structure and Interpretation of Computer Programs, Essentials of Programming Languages, the Little Schemer books, Lisp in Small Pieces, Programming Languages: Application and Interpretation, and the http://library.readscheme.org gold mine - totaling well over 150 words of interest. When I program for fun, scheme is my first choice. When I program at the day job, scheme is my prototyping language of choice (to the annoyance of my parenaphobic coworkers). R^5 is complete enough for my uses, though I would like to use scheme for more. Individual implementations have addressed the r^5's shortcomings but those solutions are not portable across implementations. One of the most intriguing aspects of scheme is the language's malleability, not just with the program design space but within the implementation space. There are scheme implementations designed as embedded languages, application languages, and scripting languages. I like being able to use one core language in each of these spaces but r^5 is a bit small for a core. Sometimes I really want to catch an exception and being able to write a library for one implementation and using it in another would be really, really nice. I've read the early drafts and lurked in the review lists, waiting patiently for the final draft. Perhaps I should have been more involved earlier. Peter Norvig advises programmers to get involved in a language standardization effort as a way of mastering programming (http://norvig.com/21-days.html). He also advises 'Have the good sense to get off the language standardization effort as quickly as possible.' I'm afraid I'm following his advice in reverse. When are you kicking off r^7?
I have spent a lot of time and effort in the past developing software in Scheme, as a public advocate for it's use both in cyber-space and in the corporations that have employed me, as well as participating in the SRFI editorial process. The primary attraction to me of the language has always been its minimal semantic footprint, which makes it an excellent platform for long-term software development projects - especially those which are underfunded. Currently, I am the Principal Engineer of a startup company and we will be sing Scheme very heavily in the development of our products, and it is important to me that the Scheme learning curve remains very short, so that we can bring in new staff who, while not experienced in Scheme (or functional programming even!) can become productive very quickly.
As a participant in all the previous RNRS documents, an editor of the IEEE Scheme standard, the maintainer of MIT/GNU Scheme, and a prolific Scheme programmer, I have an obvious stake in this process, and I take it very seriously. As I've made clear to the steering committee and numerous others, the success of this process depends on the engagement of the community, which in turn depends on the process being responsive to the community's input. Consequently it would be pretty hypocritical if I _didn't_ participate in ratification. Several recent public discussions have raised issues with the current state of the standard, and contained suggestions that ratification is or might be a possible mechanism for recovery. I view this as a positive sign, that members of the community recognize they have the power to affect the process. This is exactly what I had hoped for, although I would rather see the document repaired rather than rejected.
I had my first contact with the Scheme programming language when I was still atending my undergraduate course on Computer Engeneering. The conciseness of the language amazed me. At that time I used Scheme to implement several academic projects, such as a small compiler. In my graduation course I have used Scheme to implement a Computer Algebra System as part of my thesis. My current interests are on Programming Languages, in particular Functional Programming Languages. One thing I would love to see is the possibility of easily writing Scheme programs that are portable among most of the available Scheme implementarions, so I am following the evolution of the language with interest. Most of the time when choosing a programming language I take performance issues into account. So we need more efficient implementations of Scheme. For that reason I have been working with the Bigloo compiler, although it goes away from the standard in several aspects. I plan to contribute to the Bigloo development in order to make it more conformat to the standard.
I'm interested in the outcome of the R6RS standardization process because of three main aspects of my work. First, I'm a Scheme user. As a user of the Scheme language, it is of paramount interest to me that the standard document does not deviate from the spirit of Scheme that attracted me from the language from the first place (e.g. its simplicity, elegance, and power). Second, I'm a Scheme implementor. My [soon to be released] implementation, Ikarus, is an optimizing, incremental compiler for Scheme that already implements the majority of the requirements of the current draft (5.97) including the library system, syntax-case, unicode, records, numeric tower, r6rs IO ports, among other parts of R6RS. As my implementation is scheduled to implement R6RS by the time R6RS is ratified, the outcome of the standardization process would greatly affect how Ikarus will be released and, consequently, how it will be perceived by the Scheme community. Third, I'm a Scheme graduate student. My thesis, my publications, and the courses I teach (or assist in teaching) use Scheme as the main vehicle of expression and the outcome of the ratification and potentially the future of Scheme would greatly affect my future work.
Ever since I was introduced to Scheme during my graduate career, I've found that most of programming 'just flows'. It provides powerful abstractions and an efficient compiler interface to support program development as an organic, transformational process focusing on the essential features of the problem. For my dissertation, I used Scheme to model aspect-oriented programming languages, and continue to do so in my research work today. Scheme seems to offer the fundamental 'stuff' to do Martin Hyland's 'impossible' things. The largest deficiency I encounter with Scheme is in teaching: some fundamental idioms are not standardized; specifically records, modules, and functors. But I believe that many of these are well-enough understood now to be standardized for general and instructional use. For pedagogic purposes, the existence of a standardized set of these constructs will help my students as they learn to program. Examples will continue to work between implementations and versions.
Scheme in particular (and Lisp in general) provides us with a uniquely powerful way to write programs. The methods of abstraction Scheme provides through macros and the list-based syntax have given me and many other programmers the tools to create powerful programs with quick turn-around times. The innovations that Scheme has brought to programming and computer science is evident from the many languages that have borrowed features from Scheme up until now. Hopefully, this updated standard for the language will serve as a continuing force for innovation in both programming and programming language design. As both a professional and hobby programmer, Scheme has opened me up to new ways of thinking about how to write software. I have used it to create end-user applications, scripting-style task automation, and websites. With an updated specification for the language, I believe Scheme implementations will have a more unified core to program against, maximizing the ease of developing applications that work across implementations.
Scheme is by far my most important tool and indispensable for my daily
work. This includes:
(1) I have been using Scheme in the computer science courses I am
teaching (concurrent programming, web programming, introductory
course) at the university of Tuebingen. I believe that these
courses benefited from the concise syntax, simplicity, and
expressiveness of Scheme.
(2) Basically, all scripts related to system administration that I
wrote in the last ten years are written for scsh. This involves
scripts that keep the configuration of computer labs in sync,
automatically backup servers and databases, mirror file
repositories with ftp, detect network intrusions, and generate
various statistics and reports.
(3) Scheme is subject of my research. I am working on a dissertation
in the field of static analyses. The analysis is written in
Scheme (Scheme 48) and for Scheme.
(4) I wrote several applications and libraries in Scheme, such as a
graphical front-end for scsh (Commander S), a compiler from Emacs
Lisp to Scheme, and contributed code to the Scheme 48 project,
scsh, and SUnet (Scheme Untergrund network package).
Even though Scheme is my favorite tool, very often I find myself very
disappointed with this language. With the current language
specification and "standard library" it is almost impossible to write
code that may be shared among different implementations (of which
there are certainly too many). The result is: lots of useful
libraries remain inaccessible and very often I find myself rewriting
or porting code instead of simply reusing it. I consider the lack of
a comprehensive set of easy accessible libraries for Scheme to be a
very serious if not existential problem. In my opinion, R6RS
addresses many of the portability issues and also adds some features
(such as Unicode support) that are essential these days.
I learned Scheme in my introductory computer science course at University of Tuebingen a couple of years ago. Since then I used it a lot during other classes, term projects and open source projects: For example, I wrote a dynamic name server resolver for SUnet (The Scheme Underground Network Package). Today I am a PhD student at University of Tuebingen and work as a research assistant at the Department of Computer Science, with research interests in functional programming languages. Now, I use Scheme on a daily basis: teaching, research, and, thanks to the Scheme Shell, automating all kinds of tasks by writing Scheme scripts. Scheme also plays the main part in my PhD thesis. Scheme and where Scheme is going is really important for my work. That is why I want to be part of the ratification process: Scheme is the best language out there, it is concise and elegant. I want it to stay that way! And I have the knowledge and the experience needed to judge the draft.
Scheme is the programming language I currently use the most, and have been using the most for about 4 years. Mostly, I have been using scheme to develop and use the sound editor called "SND"[1], where I have implemented among other things: SND-RT a realtime music programming language with scheme syntax [2], a software synthesizer called SAN-DYSTH[3], and the clickless playback version used in the SND dialect called SND-LS[4], and lastly an extension for the realtime graphical sound programming environment PD[5] to use SND as a realtime safe scripting and signal processing extension language[6]. All of this is done using the Guile scheme implementation plus SND-RT. I'm also a composer, and I'm using scheme as my main language for composing. [7][8] Currently, I'm working on a special kind of sound mixer, which is going to be used by school children in the music education in Norway.[9] This is made as a java applet, where the user interface is written using the SISC scheme implementation. My position as a music program programmer using scheme as the main language puts me in a situation where my vote should be counted. [1] http://ccrma.stanford.edu/software/snd/ [2] http://www.notam02.no/arkiv/doc/snd-rt/ [3] http://www.notam02.no/~kjetism/sandysth/ [4] http://www.notam02.no/arkiv/src/snd-ls/ [5] http://puredata.info/ [6] http://ccrma.stanford.edu/software/snd/snd/grfsnd.html#sndwithpd [7] http://www.notam02.no/~kjetism/mp3/ [8] http://www.notam02.no/~kjetism/notamkonsert2006/ [9] http://www.musikkverksted.no/
The current trend in dynamic language features (in Ruby, Python and others) is toward the elements already available in Scheme (including closures, dynamic evaluation, and lambdas). So, why use and promote a "me, too" language when you can have the real enchilada? The R6RS standard addresses fundamental improvements to Scheme to allow it to be used in more practical situations--bytevectors, improved port I/O functions and binary input, and standardized exception handling, among many other features. My interest in Scheme is relatively new, but, in my short time using the language, I've found many situations where Scheme is much better suited to solve the problem than existing languages in my programming toolset, specifically with its simple syntax, Scheme has allowed me to quickly develop a dynamic mathematical expression evaluator and continuation-based "green" threaded multitasker, both of which would have taken me much more time using other tools and languages. For the mainstream non-Scheme programmer, there definitely a paradigm shift in how software is designed and developed, but learning Scheme will certainly make a person a better software developer. I'm committed to work to promote the Scheme language to the rest of the development community.
I am interested in Scheme in general, R6RS in particular, because I am sometimes a Scheme implementor and sometimes a Scheme user. I helped to create GNU Guile, writing most of the code that first turned SCM into Guile. I had one false start on a new implementation with the Pika Scheme project. I am currently making a second attempt at a from-scratch implementation. I use Scheme when I can but am frequently frustrated by the functionality of the available implementations and libraries. I believe that R6RS can be an important milestone for the Scheme community but I also believe that the current draft is simply wrong-headed in a number of ways. I have a very simple-minded but, I believe, useful view of what Scheme is and what The Report should say about it: Scheme is a design pattern for programming languages. The pattern applies in a context where we just assume, a priori, that we have a lisp-style run time system (a tracing GC, cons pairs, symbols, well thought-out numeric types, etc.). The design problem is to implement, on that run-time system, with as little effort as possible, as powerful a lisp as we can -- and -- the same language we implement should also be ammenable to static analysis in support of highly optimizing compilation. You can describe the Scheme-pattern's nature in lots of different ways: it's a three-register machine (code, environment, dynamic context); it's reducible to a minimalist applicative-order-evaluation lambda calculus; it's a more or less direct translation of an idealized fixpoint semantics for algol-class language; it's, amazingly enough, more or less the exact some EVAL code as an Actor language that was arrived at via a completely different thought process; .... It is simultaneously, and *simply*, all of these things at once. And that's why Scheme is important in history. In isolation, it might have just been a way to simplify the code in a compiler (the rabbit thesis) or a hack for making tiny-yet-powerful interpreters (e.g., SIOD). But it was quickly recognized that the same insights, the same code, reflected some of the (still) best thinking in programming language semantics, and was being independently invented for very different reasons (Actors). Not only was the design problem solution effective: it seemed (and arguably seems) to be some a priori aspect of Nature. The Scheme solution exists independently of its multiple re-inventors who each arrived at the same thing but from such different directions. Closures as the be-all-end-all of data structures; continuations, lambda, and application as the be-all-end-all of control; and a unified approach to syntactic abstraction: Scheme is not a programming langauge but a foundation on which programming langauges may be built. It is a reframing of the programming language problem that says brand doesn't matter: the liberty of continuations, lambda and apply, and syntactic abstraction are all that matter. Given those freedoms, anyone may have and use whatever language they like. (c.f. Lewis' Humpty Dumpty). R6RS, in my view, has a simple job. It needs to relax constraints on syntax and extend the reach of syntactic abstraction so that implementors may compete and discuss various ways to permit Unicode text or homogenous array constants in source. It needs to adopt a tighter, more aesthetic, more liberal definition of some basic data types (characters first and foremost) so that implementors may compete and discuss various ways to map Unicode into implementations etc.. It needs to introduce *just enough* new mechanism to support separately compilable yet interpretively useful modules. It needs to give a mechanism for adding new disjoint types. And then it needs to stop. Just there. That's *all* it needs to do. R6RS does *not* need to be split into two parts, vastly extended in length, and to try to usurp all future research and competition to create a standard library. Scheme's role is market maker, not king.
My job is to write software to solve problems for which no other solution exists, in other words, I am an IT software consultant I want to see more "general purpose programming language features" (GPPLF) added to Scheme. Two simple features that by name seem so small but in implementation are so huge are modules and exceptions. These features are so, so critical to real world programming. Standardization here critical important to allow me to use the distribution best suited to the task at hand; for example developing in DrScheme and deploying on Chez. Any good language eventually becomes a general purpose programming language for a very simple reason; *people use it*. The additions in R6RS are about natural growth (simple as possible but no simpler). The addition of an object system, for example, would have been outrageous. My stake in the outcome of this process is to see a Scheme standard that better reflects the needs of the on the job programmer who needs to solve problems using GPPLFs because it will make it easier for me to sell folks on Scheme but more importantly it will make it easier for me to do my job.
i like to write (and sometimes read) scheme programs. in the process, i learn about the pet implementation that i maintain (a fork of Guile 1.4.x), about scheme, about programming, about the problem domains (see web-page-url) and about my shortfalls as an amateur practicing philosopher. i'm interested in voting on r6rs since it will affect the future of the pet guile as well as how i continue my coding ruminations. if i am to support myself and my family with scheme, it is better to know than to not know its direction. according to M-x tex-count-words, i'm nowhere near the 150 word requirement, so this message is likely not to get me voting privs. but you will have read it anyway and so will know who you will be excluding. who knows, you might even remember the non-valid responses and think about them later. like scheme, people like to promise but sometimes never force.
I've written three Scheme compilers, based my dissertation on Scheme, and am now writing commercial software in one of my Scheme variants. For me Scheme is the ideal language with which to explore a problem. The key features that make Scheme a useful prototyping language are dynamic typing, an excellent interpreter, and macros. However, Scheme has not been able to build a vibrant community on par with Python and Perl because, in part, it has lacked a common module system. This is absolutely esential for Scheme to grow beyond its primary audience of captive CS101 students. Along with a module system Scheme needs facilities for library writers to communicate with each other. This is primarily through the exception handling mechanism and common record system. Together this should make it much easier to pool our collective efforts to build a code library comparable to more popular languages. Without these features the Scheme community will remain fragmented between not-quite-compatible implementations. Scheme remains, even today, the most productive language for me to think in. Please don't make me use Python.
I have used Scheme for research on Quantum Computation. See, for example, the paper: A lambda calculus for quantum computation, SIAM J.Comput. 33 (2004) 1109-1135, which develops a linear lambda calculus for expressing quantum algorithms. Important in exploring the ideas and checking the correctness of the paper was a simulator for this calculus, written in Scheme and available at http://www.het.brown.edu/people/andre/qlambda/index.html. I was the author of SRFI-45: Primitives for Expressing Iterative Lazy Algorithms, SRFI-57: Records, and SRFI-72: Hygienic macros, and I have taken an active interest in contributing to the discussion of several other SRFIs. I am the author of one of the reference implementations of r6rs draft syntax-case macros and r6rs libraries, available at http://www.het.brown.edu/people/andre/macros/index.html. I find Scheme attractive because of its simplicity and minimalism, and would like the language to retain some of this flavour even as it is extended to become more powerful. I therefore intend to exercise my vote to help ensure that the document addresses the r6rs mandate, does not contain inconsistencies or ambiguities, and does not exceed its mandate with unnecessary additions or unnecessarily complex APIs.
I'm a long-term Scheme user for both academic and free-time projects. The Scheme standard interests me because it defines the language I'll be working with in the future. Voting on the draft ratification is an important matter which because it defines not only the language I'll be using but also the amount of effort I'll have to put into my work if I want to make my code portable between implementations. Although Scheme should, in my opinion, be designed to be a small language it should contain all the basic modern features required by current modern programming languages in order to provide implementation developers and users with a powerful, expressive, and easily portable programming language. The definition of a poor standard will hinder my development, my work, Schemes progress as a programming language and its world wide usage. The standard defined the language. I want to be part of its draft ratification.
I am a founder and Director of Untyped Ltd, a company that provides custom web application development services. To date all our projects have used Scheme and we have developed a significant code base (over 40'000 lines) of pure Scheme code. Compared to our prior web application development experience using other languages, primarily Java and PHP, we maintain we gain a significant advantage by developing in Scheme. The use of continuations is the best known example in the community, but many other features, such as macros and s-expressions, also play a crucial role in our framework. Of course we pay a significant cost for developing in Scheme, that cost being the necessity to develop many of our own libraries, or to fix bugs in existing libraries that have not been tested under the load our applications experience. A better standard Scheme would be a very significant boon to us. More developers means more libraries, and better tested libraries, reducing the cost we pay for using Scheme over more popular alternatives. This will make our business more viable, which in turn will allow us to drive forward the commercial adoption of Scheme.
I publish several commercial applications which embed scheme interpreters. These uses would only benefit mildly from your efforts, because embedding an interpreter means you're married to it regardless. However, I also use scheme for scripting and support applications. Unfortunately, these internal applications end up being tied to the implementation because of incompatabilities. Specifically for me, the issues are hashtables (or 'hash-tables' in some systems), modules, the error function (bigloo REQUIRES 3 args while PLT accepts 1-3), structs, and non-heigenic extensions to syntax-case. There'd be more, I'm sure, but I'm relunctant to investigate implementation extensions just because of this lock-in factor. I use PLT, Bigloo, and scsh for internal apps, and embed using libscheme, tinyscheme, CLRScheme, PLT and Bigloo. Please don't hold me to the 150 words--I feel like I'm rambling already.
My interest in the Scheme standard stems from my early exposure to Scheme as an undergraduate writing evaluators and compilers for programming languages. Struck by the simplicity and expressiveness of the language, I felt I had finally found something worthy of study in the field of computer science. I have since used Scheme to teach the very undergraduate courses that made me want to become a computer scientist. I have also used Scheme for the prototyping of the research ideas and software development. I provide feedback and patches to several Scheme implementations. Since 2004, I have acted as an editor in the SRFI process and I've been involved as a member of the Scheme community in the public portions of the R6RS review process. My hope is that Scheme stays true that simplicity and elegance that first struck me and my involvement has been motivated in large part by this desire.
As a student I was attracted to Scheme by its simplicity, dynamism and expressiveness. My Master's and PhD theses focused on the efficient implementation of Scheme. Since then I have been involved in programming language research, and Scheme has been my language of choice for exploring the design and implementation of functional programming languages. I have written several papers related to Scheme and have taught Computer Science to many students using Scheme. I am the author of a few implementations of Scheme including Gambit, which is well known for its performance, portability and conformance to the Scheme standard (indeed the only fully conformant Scheme to C compiler). I am a founder of the Workshop on Scheme and Functional Programming and a member of its steering committee. I served on the Scheme standard's editor's committee as editor-in-chief. Scheme has been an integral part of my daily activities over the last 20 years.
I am a commercial user and implementor of Scheme. As a user, I would like to use Scheme in more commercial projects. However, the absence of a standard for Scheme that encourages and facilitates distributing and porting code is a powerful detriment to the usage of Scheme in such environments. Moreover, I use several Scheme implementations, and sharing code among them is at best tedious and at worst impossible - a more substantial standard supported by several implementations would alleviate this problem. As an implementor of Scheme 48, I would like Scheme 48 to be a more viable platform for running Scheme code. Right now, it only runs code writting in pure R5RS Scheme (which is scarce) or code written specifically for Scheme 48. A more substantial standard would increase the amount of portable code, and thus increase the amount of code that runs on Scheme 48. I am also the project editor of the standard, and thus some aspects of my reputation and self-esteem depend on a successful standard.