Voter registration for the election to choose a new Steering Committee is now closed. The following is a listing of the electorate:
I currently use Scheme in all my major projects, and most of the little ones as well. This work includes research in Computer Science, but also includes commercial products and Business Applications. As such, the direction of Scheme has a strong bearing on my future development direcitons. I use multiple scheme implementations, and generally provide casual support to new users of Scheme. I also teach, and use Scheme whenever possible in these contexts. Scheme ought to be generally useful both in the research field and in the classroom and in the business world.
My involvement with Scheme is in many aspects. First, my Scheme implementation, Ikarus, was the first to support a major part of the R6RS standard. Second, all of my academic work (teaching, published papers, etc.) are based on Scheme. Third, I use Scheme on daily basis for many projects. The outcome of the R7RS process and how Scheme is shaped in the future directly affect all aspects of my work and thus I would like to participate in the elections for the Scheme steering committee.
I started using Scheme as a freshman thanks to Prof. Christian Queinnec who did a great job in teaching us during our whole studies the art of designing languages. I went from Scheme to OCaml, Haskell, Erlang and Common Lisp, and found many things that needed to be improved in each language as well as others without which I can hardly live. I still use all of them depending on the problem I have to solve. Yet, the language where I'm involved the most is Scheme (mostly through Gambit-C). I do like the simple design of Scheme and its expressivity, but there are many points that irritate me, as I didn't go through the whole design process since it's been created. I do have a point of view which is more practical that what most maintainers whom I've met seemed to have, and I do believe that Scheme must be "split" for it's sake. Keep a small kernel à la R4RS, and have a standard lib next to it, that evolves at its own pace. Keep what's necessary, define it from A to Z (no more "undefined behaviour", please!), then add everything else into the standard extension (hash, filesystem interactions, SRFI-1, threads, some useful macros...) and bundle the whole as Scheme. No more sparse and uneven SRFIs that aren't implemented with the same API anyway. In short, I do believe that Scheme has to remain minimal (kernel), while allowing people to run useful code on any implementation that follows the new standard (kernel+stdlib). There is also nothing wrong about enforcing some design decisions and not being backward compatible, provided one lets the language evolve more often that once every decade... In that sense, I consider participating in the election of the next steering committee by voting, hoping it will hear my voice and that Scheme will not be anymore a generic name for a class of programming languages implemented without any interoperability by various academic labs...
I am a professor of astronomy at the principal Mexican research university. I use Scheme almost daily in my research and teaching. I use it for numerical astrophysics, including a large code to model the structure and spectra of protoplanetary disks around young stars. I use it for teaching, to calculate exemplary models of stellar atmospheres. I use it for instrumentation, to control detectors, filter wheels, and an adaptive optics test bench, both in the laboratory and at the telescope. I use it for publishing, to script the graphics in all of my papers.
I use Scheme to get real jobs done. Sadly, I have yet to wrangle myself a job where I get paid to do this, so for now, I can only use it for my own projects (such as Ugarit, a backup/archival system written in Chicken Scheme: http://www.kitten-technologies.co.uk/project.php?project=ugarit) . But I'd *like* to be able to convince people to pay me to work in Scheme, as I believe it is the most productive development language around right now. But, I think R6RS has jeapordised that a bit. I won't get into a rant about it here, but I feel R6RS has started to take Scheme away from being a small, elegant, core upon which standards like the SRFIs and each implementation can build. I want a minimal core Scheme, upon which higher levels can build facilities like object orientation; R7RS does need things like a standard way for code to declare that it requires a particular extension to it. I don't think it needs things like records - how to extend the type system to cover disjoint record types might be worth standardising, or it might be worth leaving to the implementations to reconcile with their data model implementation. I believe that such a simple Scheme core allows a variety of implementations, while the SRFIs provide a forum for implementations to be compatible where they can; yet allowing them to be different if they want to. This allows innovation - Scheme has an unprecedented number of implementations, and although code compatibility between them is currently rather poor, I think the SRFI process is helping there in ways that the core language itself shouldn't; but the core language can help the SRFIs do their work, by staying minimal while recognising the existence of extensions. The wide variety of implementations promotes innovation into low-level implementation techniques such as Chicken's use of the CheneyMTA system, and specialised implementations for embedded systems and the like! And, so, I'd like to vote for the future development of Scheme, to keep it a great fast-moving language, with a simple core that's easy to implement, yet onto which SRFI reference implementations can easily be ported to bring up a fully-fledged powerful development environment!
I have been using Scheme for almost four years now. I use it mostly for studying programming languages and programming in general, prototyping and testing new ideas, but I have also developed and sold applications written in Scheme to customers. I believe Scheme is nowadays a maximum in the design space of programming languages and is the language of choice of some of the best hackers of the world. I thus deeply wish that Scheme gets getter with each new standard revision.
I've been programming in Scheme for over 8 years, have contributed significant amounts of code to the Gauche and Chicken Scheme implementations, and authored the (withdrawn) SRFI-56. I've also written many popular portable libraries, including a fully R5RS-portable pattern matching library, the only Lisp regular expression library with a DFA conversion, and a streamable HTML tree-parser. New ideas I've introduced include a flexible loop syntax which has gained a second implementation named "foof-loop," as well as an extremely extensive combinator-based formatting library. I use Scheme for all my personal projects, for my current research and MSc thesis, and use my own Scheme-implemented HTTP and SMTP servers.
My interest in Scheme standardization remains what it was the last time the Steering Committee asked for it: 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.
I've been using Scheme since eight years. One of the major programs I wrote in Scheme is the server side scripting in the SUnet webserver. I also tried to use Scheme for administrative tasks by writing small scripts in scsh. However, I usually failed to use Scheme for adminstrative tasks due to various restrictions and impossibilities in Scheme. R5RS was not aware of character encoding, and the current standard R6RS has no or does not endorse standard routines for looping through text files or processing XML files, and it misses standard data structures beyond lists and vectors such as hash-tables, to name a few shortcomings. So, I would like to see the Scheme standard to evolve in a way to allow more real-world programs which can be (more) easily be ported between various Scheme implementations.
I have been using scheme for a couple of years, both at work and on home, hobby projects. I started using it both because I wanted to learn something new about programming languages and because I was finding the Python code that I had been working on at the time both too slow and too ugly. Pleasingly, I believe that I have found what I was looking for on both counts. My main scheme-using project involves reading graph descriptions in XML (produced by a different program) and then performing a variety of manipulations. It is, perhaps, something of a compiler. This is quite a different style of program than I have created for most of my career, which has chiefly involved numerical analysis and embedded systems. I would not want to write this sort of thing in my usual C, assembler or Java (I avoid C++.) I would like to see scheme evolve in directions (or even just implementations) that can support both of the latter fields as competently as any other language, and it seems to me that the scheme mantra of providing power by removing limitations should permit it, even if that doesn't seem to be a particular focus of the scheme implementations that I am familiar with (not many).
I've been hacking on and on top of Guile for about 6 years now. I wrote much of the compiler that will be in the next version of Guile. I am interested in doing the vast majority of my future hacking in Scheme, and for that reason am interested in the process of language standardization. I would also like to publish my existing libraries for other Schemers to use (not just Guilers), and to use libraries of others. Besides that, as far as language "flavor" goes, I am particularly interested in Scheme as a flexible, dynamic programming environment.
Scheme is my favorite untyped language. I have delivered commercial applications in PLT Scheme, Gambit, and SISC, depending on requirements, but I've also had occasion to use many other implementations. I implemented an executable version of the denotational semantics for R5RS, in pure R5RS Scheme. I host the Community Scheme Wiki (community.schemewiki.org), which runs on Gauche Scheme, and the Scheme Cookbook (schemecookbook.org), which relies on a Gambit Scheme server for highlighting Scheme code snippets. I served on the Scheme Editors' Committee responsible for developing the R6RS. I have also foolishly accepted a nomination from some unknown sadist, as a candidate in this election. My use of multiple implementations gives me an added motivation to be interested in Scheme standardization: I want to be able to write code that's reasonably portable between Scheme implementations, without too much trouble. The R6RS has made large strides in that direction, but there is more work to be done, and I intend to contribute to that process.
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 personal programming projects. I TA-ed 6.001 several times under Profs. Abelson and Sussman. That taught me the great value of Scheme as a teaching language. 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. I continue to make small contributions to MIT Scheme 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 in the IEEE Scheme standardization process in person, and participated by email in the R6RS process. While I was disappointed by the final R6RS draft, I voted in favor of it to try to make Scheme a language more suitable for practical projects. Now it's time to swing the pendulum back a bit and make the next standard a better compromise between the diamond-like jewel Scheme was before R6RS and the practical, everyday programming language that many of us have always wanted Scheme to be.
I have long been a Scheme programmer, and have found Scheme quite useful for programming language experimentation. However, recently (with the release of R6RS) I have become concerned about the direction that Scheme is going. In particular, I was disappointed with the structure specification, and I found it peculiar that the definition of program structure seems to depend on the dynamic behavior of the expression. I anticipate that the right nominee will be able to get Scheme back on track, and perhaps even fix some of these problems.
I currently develop and maintain an implementation of R6RS built on top of Gambit Scheme (http://smyles.com/projects/r6gambit/). I've commented on the R6RS standard while it was being developed. I have been developing applications in Common Lisp and Scheme for the past 3 years. The reason I'm interested in participating is to help establish a fair process whereby the evolution of scheme can continue. I would like to see a process that reduces unnecessary controversy. There are lessons to be learned from the last round and I will be voting for people that have learned them and can be fair and impartial on the result of the next round of standardization.
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 a wide variety of applications. 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 4.0, Guile, JScheme, MacScheme, MITScheme, PLT Scheme (DrScheme and MzScheme), Pocket Scheme, RScheme, scheme->C, Scheme48, SCM, SCM Mac, scsh, SISC, 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. Scheme-Requests-for-Implementation I wrote: SRFI 47: Array SRFI 58: Array Notation SRFI 59: Vicinity SRFI 60: Integers as Bits SRFI 63: Homogeneous and Heterogeneous Arrays SRFI 70: Numbers SRFI 94: Type-Restricted Numerical Functions SRFI 95: Sorting and Merging SRFI 96: SLIB Prerequisites 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. 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.
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 but I have been following the progress of r6rs with avid interest.
My interest in the Scheme Standardization Process is two fold. First, I'm a professional programmer who depends on using Scheme in production projects. A better Scheme standardization process, means a better Scheme Standard, which in turn means more consistent and hopefully higher quality Scheme implementations. This will only serve to make the lives of industry programmers better. Secondly, I was both excited and ultimately disappointed at the outcome of the R6RS standardization process. When the R6RS process began, I felt like it was an opportunity to make a leap forward in the Scheme language. Instead, the result seemed to be a fractured community and a bittersweet victory for some, and outright disappointment for others. But, the exciting part is that there's an R7RS ahead of us. I'd love to help us learn from our mistakes, and help to produce a better process, and thereby language, in any way I can.
Had I registered to vote last time I might have stated: " I have been using Scheme, the best Lisp in history, for about 15 years. To me, the defining characteristic of Scheme is minimalism and elegance. I have sympathy for those who want scheme to become a viable alternative for building not only research prototypes but also commercial applications. But, 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. We only need to agree on adding a few missing but commonly implemented features. Records, low level macros, a condition system etc. " Now we also need a rescue plan.
I'm interested in relatively high-performance Scheme implementations that can be used for sophisticated (read: somewhat large and complicated) algorithms in Scientific Computing. These problems include Monte Carlo simulations, numerical partial differential equations, computational number theory, the computable reals, stochastic differential equations, etc. So I'm interested in various aspects of the Scheme programming language that affect this goal: Macro systems, module systems, object systems, floating-point arithmetic and arithmetic in general, the parts of the language that make it easy (or not) to generate valid C code from Scheme (since I mainly use the Gambit Scheme->C compiler), etc. I also act as an implementer, having built the bignum system for Gambit. (This was not a totally useless endeavor, as it uses some algorithms not in gmp, at least one of which will be adopted by gmp in the next major release.) Obviously, languages standards influence these activities.
I have been a part of the Scheme community for over 20 years. I am the author of the libscheme Scheme implementation that became the starting point for the popular MzScheme system (although I don't believe any of my original code lives on in that implementation). I am interested in the development of a Scheme standard that describes a language that is suitable for building large, real-world applications without resorting to implementation-specific features, while also staying true to Scheme's goal of beauty and simplicity.
I teach SICP (should I have spelled that out to pad the word count?) as our first course for CS majors here at Berkeley. I am also co-author, with one of my (then) students, of _Simply Scheme_, a SICP "prequel" used in our zeroth course for people with no prior programming background. Although not a Scheme implementor, I've dipped my toes in the water of using Scheme as the basis for software development. Most significantly, a team of students under my supervision developed a Scheme interface to the Google mapreduce software (actually the Hadoop free version). Mapreduce's roots are in functional programming, but as actually designed at Google, mapreduce uses an ugly iterator-based interface. We wrapped a functional interface around the Hadoop code, so our students can say (mapreduce (lambda (key-value-pair) (map (lambda (wrd) (make-kv-pair wrd 1)) (kv-value key-value-pair))) + 0 "/gutenberg/shakespeare") and get back a SICP stream of (word . count) pairs indicating how often each word is used in Shakespeare's plays. The arguments are a mapping function to be applied to each key-value pair (representing one line of text), a reducing function, a base case value for the latter, and the name of a file or directory in the distributed filesystem. See http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-34.html But my interest in the RnRS process is as an educator, not as a software developer. As an educator, I find two crucial excellences in Scheme: (1) it has an interactive REPL, so that students can jump into using it without hassling with an IDE; and (2) it is small, simple, elegant, easy to implement if you're not worried about efficiency, and, as a result, a striking piece of evidence for the importance of a coherent fundamental design in a programming language. Recent developments have threatened both of these, turning Scheme into something much more like a single-namespace Common Lisp, making it a redundant part of the universe of programming languages. It is my deepest hope to slow down, or perhaps even reverse, this change.
Like many others, I fell in love with Scheme under the spell of SICP, and also the Little Schemer series. Twenty years ago I wrote a tutorial that became part of the documentation for the TI Scheme implementation, and I have written about Scheme many times since then in my work as a math-and-science journalist. I am a user of Scheme systems rather than a producer of them, and I see the language more as a medium for exploration rather than as a tool for software development. This is a constituency that was once at the center of the Scheme community, and it's an aspect of the language's heritage that I would not want to see forgotten.
I am a graduate student at Northeastern University, an advisee of Matthias Felleisen, and a member of the PLT research group. I have contributed to the Scheme community through software, original research, and teaching. I have written code for both the PLT and Larceny distributions of Scheme. I have attended two prior Scheme Workshops. My research software is written in Scheme, using features that I believe are unique to Scheme, and I have a vested interest in the future of the language.
My interest in Scheme come from its simplicity and ease of use. My first contact with Scheme came in a compilation class where I wrote a small Scheme to JavaScript compiler. I have since used the language for most of my application writing needs, from small scripts to bigger applications such as games and compilers, because it is simple to use and allows me to write elegant code in an efficient manner. Lately I have been mostly interested in using Scheme to develop web applications.
I have been a Schemer siner 2002. I have translated the book `How to Design Programs' (a introduction of programming book in Scheme) into Chinese. I have using Scheme in various places, including homework, programming tasks (aka job). I have taught Scheme to several friends. Currently I'm working at Utah PLT on macros. In my opinion Scheme should be easy to learn, good at rapid proto-typing, well suited for pro- gramming language researches and have a clear semantics. For me R6RS failed to achieve these (even worse than R5RS).
I've participated in Scheme standardization since its inception, and also maintain the MIT/GNU Scheme implementation, so consequently I have a deep understanding of the issues involved. While I am not too interested in the details of standardization, I am very interested in the process of standardization. My dissatisfaction with the previous round of standardization, other than in the outcome, is that there were a number of process failures that were hastily patched when it became clear that there were problems. The patches helped, but didn't completely compensate for better planning. I'm not sure any of us could have done a better job at that time, but I do think there are lessons to bring forward into the next round. Since the steering committee is responsible for process, it should be composed of those who can effectively apply these lessons.
My interest is that the community around Scheme will be continuing to cooperate and share ideas and implementation parts positively. I think the committee should be leaders of the communication process; they could develop and distill ideas on their own effort, but also just help collect and support ongoing existing ones. And community interaction should be simple--no more words or steps than necessary to convey an information. And transparent. Any need to say more?
Although not directly involved in Scheme programming at the moment, I have had the great pleasure of basing first my thesis work on Scheme and later had the great fortune to convince my employer to base a new network management framework on Scheme. As part of that, I was even registered with FSF to allow us to send code back for development of Guile Scheme, our scheme of choice. I have for many years been an avid proponent of the greater Lisp family and is most interested in furthering its place in the world.
I have been working in the Lisp/Scheme domain for more than 30 years. I have written some papers and books on these programming languages. I also had convened the ISO Lisp working group for some years. Therefore I'm considering myself as qualified to participate to this vote. Even if I did not want to be a candidate for the steering committee, I am still willing to participate. I'm interested in Scheme future, I'm unhappy with the current state of Scheme and I wish it could change.
I have been using Scheme to expand my horizon in what is possible in programming languages since about 2003. Since then I converted to using Scheme as my primary programming language for personal/recreational programming. Lately I also somewhat jumped into the territory of library programming by porting the Tiny CLOS library to r6rs. My interest in the standardization process of scheme is twofold: 1. For personal programming I want scheme to maintain the characteristics which make it so dynamic and perfectly usable to throw together and experiment with different concepts. 2. For my professional carrier I would of course like to (someday) be able to actually programming in a big company using scheme and make a lot of money out of it ;)
I have been writing compilers and interpreters for several years for various languages. My current compiler project uses a dialect of Scheme as an intermediate representation that unfortunately does not respect the standard. I am also writing interpreters that are designed to run on severly resource constrained devices, and I would like to use a version of Scheme internally. Instead I have found that my best option is to use Lua. It is my opinion that it is not possible to conform the current Scheme standard and address the needs of interpreters embedded in small application and running Scheme on embedded devices. I think that Scheme would benefit greatly from the introduction of formally defined profiles, such as for embedded devices, application scripting interpreters, and for distributed computing.
I am one of the software architects behind the GENCOL mathematical optimizer, which solves combinatorial problems by branch-and-price. I currently work as a Software Architect specialized in Operations Research at AD OPT, a Kronos Division, where I contribute to the development of crew planning, management, and optimization solutions for the airline industry. Over the years, we've had three main motivations to use a flexible interpreter: - to efficiently develop multiple variants of heuristics and control flow algorithms on top of our low-level core libraries (e.g., network algorithms, mixed integer linear programming libraries); - to define a domain-specific language (DSL) for expressing dynamic programming rules; - to manipulate problem data using a functional reactive paradigm. So far, we've used R5RS Scheme as the specifications for our interpreter because of the following capabilities: - we could "easily" write our own implementation on top of the infrastructure library used for our solvers; - we can provide access to solvers' data structures and functions as Scheme custom types and procedures, seamlessly sharing memory management primitives and exception handling mechanisms; - functional programming paradigm (formalism, abstraction); - sound macros (DSL, abstraction); - clear semantics and small runtime library. My interests in Scheme standardization derive from my use of the Scheme language both as a developer and an implementor and include: - to focus on the "core" Scheme language and its semantics; - to make it easy to write scripts and evaluate Scheme code dynamically; - to favor alignment with ISO C when it is both rational and possible.
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, me included. Getting a new, standard version of Scheme is important to me; it will hopefully 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 am concerned about most matters touching on the Scheme language and have previously been involved in the SRFI & R6RS processes. I also use Scheme commercially for my own web-projects as well as for internal data analysis at various employers. While my public advocacy has declined somewhat in recent years, I am still a heavy user and am currently participating in the process of designing a Scheme-family language with a focus on high performance numerical computing. My specific concerns with the Steering Committee membership are in it's ability to adjudicate the standardization process - this is more important than it appears and is a vital part of ensuring the quality and relevance of the standard into the future.
As an everyday Scheme programmer, I believe that the new standardization of our language is critical for the Scheme community. Indeed, the last standard really divided even more the community members, and this is *really not* what we need. I would like to participate in this vote to ensure that the comitee of the next standard will create a standard that will bring forward good/new ideas to the language, but such that it will make the different implementation specific communities closer one to another, and not farther. We would *greatly* benefit if a good standardization would enable us to easily share code between the different implementations of Scheme.
Scheme is a beautiful language. It was the first beautiful thing I encountered while studying computer science. The addiction has been raging unabated ever since. I declare a stake in the standardization process as a teacher, implementor, user, and researcher. I have taught Scheme-based courses at Brandeis and Northeastern. I have contributed to several Scheme implementations. I have, on multiple occasions, heard every one of Olin Shivers' jokes. I brandish weapons of mass control. I have acted as an editor in the SRFI process since 2004, and as an author since 2008. I have published at the Scheme workshop and currently serve on the program committee. In other words, I am a member of the community. As a free variable, I take pride in the words 'Ich bin ein Schemer!'
I have known and used Scheme for 2 years. 3 years ago, I read about Lisp ideas and was significantly influenced by them, but it wasn't until I learned more about Scheme that I was hooked. Scheme is by far my favorite language and I want it to continue to advance. Scheme has so many merits that cause me to believe its future can be very bright. My first year with Scheme I spent reading about it and programming many experiments to become familiar with its various aspects. This last year, I have written a collection of R6RS software that explores and utilizes features of R6RS and I have ported others' software to R6RS. This has given me direct experience using R6RS and with its flaws and benefits. Because of these things, I have an interest in the future of Scheme and I believe I am qualified to vote on it.
I have become interested in functional programming languages by introduction through a university course in compiler construction. I learned of Scheme shortly after and it has since been the language I have been interested in the most. Improvement of a Scheme compiler was the topic of my diploma thesis at university. I have used Scheme as my main programming language in several courses and for personal programming activity. The Scheme language, by means of its small and concise, yet useful core makes it enjoyable to experiment and work with. By casting my vote for the members of the next steering committee, I hope to be able to contribute to making sure the language will continue to evolve into a direction that serves the needs of practical programmers and educators alike.
I have been a Scheme programmer for more than 15 years now and a strong supporter of Scheme in the industry. I was the first organizer of the Montreal Scheme/Lisp User Group between 2004 and 2007. I am also the author of a popular Scheme development environment for the Eclipse platform, called SchemeScript. As such, not having a Scheme standard supported by all major implementations makes it hard to provide powerful tools usable by a large proportion of the user community. Being an open-source project, I cannot spend all the time required to support all implementations. And I don't want to bind my tools to a single implementation. I am thus very interested in the standardization process as a good Scheme standard will allow us, tool developers, to provide more useful tools to Scheme developers on a variety of platforms.
I have been using Scheme for about 16 years, I have been part of the PLT Scheme group for more than 5 years. I have been involved in teaching using Scheme for most of this period (in various universities and in a commercial setting); I wrote large amounts of code in standalone projects, PLT libraries, and various tools that use Scheme; and I implemented many Scheme-like languages on top Scheme. It is important to me to see Scheme becoming more successful.
Scheme is one of my most important tools and indispensable for my daily work. I'm using scheme mainly to produce prototypes of a large commercial software application and as tool for generating test data. More and more often, I wish that I had access to same rich set of libraries Java or Perl users have access to. I hope that the Scheme standard will develop into a direction that enables sharing libraries across Scheme implementations.
I'm interested in Scheme and its implementation for nearly two decades. I like the original spirit of the language, its conciseness and expressiveness. It is my language of choice for all my programs, as well as for my text documents. As an implementer, I'm particularly interested in the standardization process of the language and I hope that the language will continue to evolve. As some other Scheme implementers I was disappointed with the last incarnation of the standard and I feel that we need to start as soon as possible a new round of standardization process to unify the (too small) Scheme community which was somewhat divided by R6RS.
I'm using Scheme for more than 10 years to write many kind of application. Scheme was the language I used to develop JIT Compiler on FPGA. I made a lot of compiler prototype to study the implementation of modern programming language. Because DATA and CODE use the same syntax, I often use it to describe/process DSL that describe compiler phases/optimisations. Basicaly, Scheme is my little Swiss Army Knife. My interest on Scheme standard is to try to keep the spirit of Scheme which let me do efficiently "my job".
I have used Scheme for 12 years: I learned to program with MIT Scheme, then shifted between Kawa, Scheme48, and arrived at PLT Scheme and Larceny as my preferred development environments; thus I appreciate past Scheme standardization efforts and understand the need for further improvements to the standard. During the last four years I have contributed to the Larceny runtime system and its Twobit compiler; thus I appreciate the concerns of both users and implementors. That's 75 words; I am tempted to stop there (and am curious to know whether the above would be a "sufficient" statement of interest). I will just add that I was interested in the R6RS development process and was active on the r6rs-discuss mailing list. After seeing the community's response to the R6RS, I thought it important to register to vote on the membership of the Scheme steering commitee.
I've been interested in Scheme for a long time, and before it existed, in Lisp for even longer (I'm older than average programmers!). I worked at several Lisp interpreters, now obsoleted together with their supporting machines. For Scheme, I worked at some implementation and packaging aspects of C-Gambit, many years ago. Quite involved in the GNU project at the time, I've been implicated in Guile politics before it existed, trying hard (but unsuccessfully) to get Richard Stallman to better respect Scheme standards. I used Scheme in my previous company for massive (and sophisticated) text handling duties. Nu Echo, my current employer, is using Kawa in production works. As a long time Scheme lover, I've always had special interest in the preservation of Scheme's clarity and purity, since this is what originally attracted me in this language.
I'm interested in the future of scheme for a number of reasons. In my spare time I develop computer games written in scheme and am working on an image synthesizer as well. The current state of scheme implementations ties this work strongly to a single implementation because it requires a number of facilities that are common to many implementations but all implemented with different interfaces. This makes it difficult to share code or reuse code written by others across implementation user bases. I would like to see standard methods for libraries or modules of code that could be reasonably portable, but I feel like scheme has strayed very far from its core values in the r6rs spec. There must be a way to get back to the minimal set of features mentioned in the first page of the original report while still providing a solid foundation for developers.
I have been familiar with Scheme from about 1995, and have been using in professionally since about 2001. (Systems I've used are SCM, mzscheme, Gambit, but most extensively Bigloo.) I am the author of the Russian translation of SICP. I feel that it is very important for Scheme to remain a language with a clearly defined and well thought out core, especially for the purposes of education. On the other hand, portability of libraries between implementations keeps the community from fracturing, and lets everyone benefit from each other's work. Considerations of mainstream acceptance are of secondary importance for me.
As one of the inventors of Scheme, and as a heavy user of Scheme I feel that I have a clear interest in this matter. I use Scheme in teaching and in research. I used Scheme in the development of the introductory computer science class "Structure and Interpretation of Computer Programs," which we taught at MIT from 1980 to 2007. I use Scheme in "Classical Mechanics, a Computational Approach," that I have been teaching with Jack Wisdom every fall term since 1994, and I use Scheme in "Adventures in Advanced Symbolic Programming," that I have been teaching in the spring term for the last 3 years. I am concerned that Scheme remain simple and elegant, as well as powerful. I was not happy with the R6RS process, because I felt that by trying to accommodate some real concerns it lost some of the simplicity of the earlier versions, so I I will try to take the next step more serioiusly.
I am an application developer at a mid-sized university. Scheme is one of many languages I use. Several of my Scheme Web applications are in production use on campus, probably a few hundred-thousand LOC, which served at their peak about 1e6 requests/day. I believe that (some definition of) Scheme hits a sweet-spot as an application-development language, and have been very happy with the performance and maintainability of my Scheme code. I look forward to a day when I can declare that my next application will be written in Scheme, and not have my colleagues look at me as if I had two heads, or were stuck in some paleolithic reverie. R6RS may have set the foundation for that future, but it fragmented the community in the process. Perhaps this was a necessary growing-pain, but my hope is that the R[789]RS processes will recover common ground among diverse Scheme communities.
Scheme has not only met, but has far exceeded its goals for academia. With the latitude of problems faced by industrial developers today; now is the time to let Scheme's light shine in the industry. As a software designer and developer, my interest in this process is that its outcome reflects the needs of "The Working Scheme Programmer". Ultimately, though, the standardization committee must serve both communities in R7RS. Until now, the essence of Scheme, "Programming languages should be designed not by piling feature on top of feature...", has served academia well, but not the industry. Consequently, the community has moved forward independently from the standard. While this is not a problem in and of itself (the SRFIs, for example, have served the community well); incompatible changes have been made between distributions resulting in frustrating incompatibilities. Solutions to standard problems like modules ought not to require any effort to be made portable across different implementations. The efforts of R6RS, the first step at addressing the needs of both communities, were largely marred by the dissatisfaction with its result. The community simply felt that the report did not hold true to the spirit of Scheme. It is that spirit which will be so important not only to the community, but to the steering committee itself, in moving forward with R7RS. At one moment in time, Scheme itself was an experiment. Scheme encourages experimentation. Sometimes experiments fail, though, and when they do, it is up to the scientist to learn from the mistake and keep moving forward. The outcome of R6RS can either be used as an excuse for the community to disband, or as a lesson on how to move forward. I choose the latter. The new steering committee needs to focus on the processes and procedures that allow for both communities to be served in the manner that best realizes the spirit of Scheme; doing so in a manner that honors Scheme's past, listens to the voice of its community today, and steers diligently towards the future.
GNU/Guile is essential to my PhD work, which assigns programmatic meanings to words and phrases of English, so that the meanings of the words in a phrase may combine via function application and composition to form a meaning representation for the phrase as a whole. I am working most closely with time expression semantics, with a view towards understanding a phrase like "just before last Thursday's morning hearing" as a probability distribution over a timeline. This project exercises Scheme especially, because I use aspects of genetic programming, automatically generating S-expressions as meanings for words. This entails generating edge cases and code that a human might only produce by mistake, and employs the beauty and simplicity of the language in expressing complex semantic interactions.
I discovered Scheme 20 years ago as a student through reading the Little Lisper and it was love! The last 20 years have been a constant effort to build the necessary tools to be able to do all my programming needs using this wonderful language that is Scheme. As such, I implemented many Scheme implementations over the years. I also coached Scheme to new programmers in a company that at one point had more than 50 programmers working full time in Scheme. Recently, in the interest of code sharing, community, ..., I spent the last 2 years open-sourcing and rewriting my own Scheme implementation that was implemented in C++ as a macro on top of other Scheme implementations. As such, my interest in the evolution of Scheme is now even greater than it was and it was always great! Thank you all for the wonderful work on standardizing Scheme over the years.
The voter indicated that he would like to submit the first chapter of Structure and Interpretation of Computer Programs as his statement. The Steering Committee agrees that this does fulfill the requirement, given that the voter did write it, and it is more that 75 words long. Unfortunately we don't have the space to reproduce it here, but it can be found online at http://mitpress.mit.edu/sicp/.
Computer Science: My major interest is in languages, the paradigms they enable, encourage or discourage (e.g. functional programming, multiple cores, etc.), 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 watched 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 scheme standardization effort will further all of my above interests and goals.
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 a vast number of very flexible compilers and interpreters for Scheme, unlike other high-level languages used in scientific modeling, and because Chicken Scheme already had many convenient libraries available. I strongly believe that one of the reasons why there are so many good compilers for pre-R6RS 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. I believe that this simplicity makes pre-R6RS Scheme the best environment for building special-purpose languages and code generators, which is a very unique and important role. I think the greatest strength of Scheme is diversity, and therefore future revisions of the Scheme standard must strive to maintain and nurture the vast ecosystem of Scheme implementations, even at the cost of reduced portability, rather than attempting to force changes that disregard the needs of small Scheme communities.
I do a large amount of commerical and non-commerical development. I'm interested in portability of code, performance, and flexibility. My company and I are currently writing games/gaming libraries, business programs, and advanced math libraries that may or may not be implementation independent, depending on standards. I'm also interested in guidelines for mathematical representation, port behavior, and non-scheme code integration. I'm looking to use scheme as the exclusive language for most of my (and my company's) programs and highly value and enjoy my coding time and effort.
As an avid user of Scheme, both personally and in my research, I am intensely interested in the outcome of any standardization processes. Furthermore, as a member of the PLT Scheme implementation group, the standardization has a real impact on me. (In particular, I manage the PLT Web Server, so aspects of the Scheme standard that are conducive towards Web-oriented programming are very relevant to me.) I'm a true believer in Scheme, so I care that the standard is well-suited to the goal of extending its domination across the computing landscape.
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 particular, I point out that the functional programming allows a precise approach suitable for developing large programs. 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 have developed 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. I am presently making it R6RS-compliant. Some people from the TeX-Live team have used it, and result is encouraging, but there are some improvements to do. It is my intention to maintain it, so I am interested in the future of Scheme.
Scheme is probably my favorite programming language. The world needs a small, elegant, and standard Lisp dialect, because such a language provides the most convenient notation for communicating programs and data. Scheme is well-positioned to fill this role. I have done a few Scheme/Lisp implementations; two were instructional toys (I was a teaching assistant for a course in Scheme for several semesters), one is half serious, and one is just very small (http://code.google.com/p/femtolisp/source/browse/trunk/femtolisp/tiny/lisp.c). I have also been through what Steele and Gabriel describe as the "rite of passage" of designing my own Lisp dialect and syntax and ultimately concluding that we're better off with s-expressions. I want to see Scheme remain (or revert to being...) concisely implementable and comprehensible, lest the human species collapse under the weight of too many lines of code we can't understand or execute. I've found that there's no better way to understand a programming language than to implement it, so if we want programmers to know what they're doing implementability could be more important than people might think. Scheme should be small enough that its core can be slipped unnoticed into a larger software package, making it easier for us to deploy our secret weapon. I also believe Scheme should bow more to "modern conveniences" to help build popularity as a scripting language (for example, an external representation of hash tables, or more generic operators).
I have come to deeply admire Scheme's design. It is fire from Prometheus, an emanation directly from the realm of platonic ideals. A small, simple language core gives us the ability to talk about procedural, functional, and object-oriented programming in their own terms and to build complex, powerful linguistic constructs out of the simple ones the language supplies. It's one of the few multiparadigm languages that address many different programming modalities through a single model, rather than being forged in one paradigm and having the others added on as "bags on the side" (e.g., C++). So why hasn't it caught on? Applications. Most software is not theoretical, but is rather written by people who have a real-world, specific need to fill. Scheme serves well as a proving ground for new language concepts, but hasn't adapted well to the application realm on its own. Rather, a variety of implementations have proliferated, each with their own set of ideas of how to extend the language to do real work on common computer platforms. I am interested in a process that bridges the gap between theoretical neatness and a common ground with which to address practical software issues. I would be a staunch advocate if such a process yielded a small, neat, orthogonal language core and a set of optional, but strongly encouraged, satellite standards for library functionality. R5RS+SRFI was a step in the right direction, but with R6RS the process took a turn towards putting too much in the language core.
Ever since I was introduced to Scheme I have been enamored by the combination of clear semantics and macros. The combination makes it a great tool for the curious programmer, who likes to experiment with either new language constructs, or self-written implementation of known constructs. As a teacher I am greatful for the energy the Scheme community has put into books and tools for students to learn programming. The innovations of the latest standard revision R6RS were important in order for the Scheme language to evolve. The long period of time between R5RS and R6RS was unfortunate, so I hope to see new revisions with regular time intervals between.
I have been using scheme for 4 years both in my academic work and in industry projects. I am currently a Master's student under the supervision of Marc Feeley working on implementing multi-processing and distributed computing constructs in the Gambit-C compiler. I have also worked on Guillaume Cartier's Jazzscheme project which is a full an open source programming language based on Scheme including a full featured cross-platform framework and a sophisticated programmable IDE. I implemented the cairo backend and ported the language to Linux/X11. Finally, I worked on several contracts for Metascoop inc., a Montreal based company that use Jazzscheme exclusively.
While I have interest in someday implementing a scheme (for the somewhat mythical value of someday guided by graduate programs and children), my primary involvement is as a user of the language. My reasons for using scheme professionally are focused on developing applications to enable research in cognitive and educational psychology as well as to provide software solutions to students. Further, as a doctoral student in educational psychology, I am interested in the research relating to scheme both as a tool for developing tools for education and as a proven language to use as basis for teaching notions of computation to learners. I've used the PLT, Guile, and Chicken dialects as well as dabbled with Gambit and the non-scheme CL (of course) and Clojure lisp dialects. My interests in the product produced by this process are to see defense of the minimalist tradition of RNRS for the core language (though I am certainly open to seeing an accompanying "standard library" document, preferably based on existing SRFIs and the SRFI process as a matter of furthering portability between implementations)
Being a Scheme advocate is both thrilling and tooth-gnashing. On the one hand, Scheme represents a magnificent "blank slate" for new features and discoveries, but on the other hand is "passed over" TIME AND TIME AGAIN in the "trendy-language-of-the-year" competition. I suppose some find that a virtue: it means that Scheme is relatively unencumbered by legions of users who kick and scream every time the language changes in even minor ways, and who write great enormous masses of truly horrible code (cf. JavaScript). On the other hand, it's frustrating to have discussion after discussion with colleagues who refuse to consider Scheme as a realistic pedagogic choice simply because dice.com shows fewer than 150 hits for "Scheme", and those results include (on the first page, no less) an advertisement for Northrop Grumman for an Antenna Engineer--clearly, an accidental use of the word "scheme".
> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc placerat, (I'm tempted to write this in dog-Latin, but I will refrain.) While fundamentally content with the results of the R6RS process, it is not, nor should it be, the final word on Scheme. Furthermore, if Scheme is to survive the current generation of Schemers (of which I am neither the oldest nor the youngest), it must be handed down. We need new bloooooooooo -- excuse me, new blood. Though I have not implemented Scheme nor used it as extensively as many community members, I still do not want to see it perish, as it surely will if it does not come up to date, discarding the non-essential while preserving the essential elements of the tao of 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 -- 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 examples and
demonstrations. My interest in the standardization process is to keep the
core language small, simple, expressive, and accessible to novice
programmers.
I have been programming in Common Lisp for a few years. I should like to have a reasonable alternative that does not enshrine years of bitrot into the language standard. Several Scheme implementations are very promising but it is hard in practice to write portable programs. Having multiple (more or less) compatible implementations is one of the key benefits of Common Lisp and it is very unfortunate that there is no strong competitor in Scheme. I am concerned about the direction that Scheme took with R6RS and hope that the addition of my small voice to the clamouring crowd will result in a better Scheme. In terms of the politics, my position is that the Scheme committee should opt for a much smaller core language standard and a much larger set of standard libraries.
I am interested for a few reasons. First, I write programs in Scheme and want the community to develop better languages, systems, and libraries for me to use. Second, I am interested in programming languages and see Scheme as a place where interesting design work and outreach might happen. Third, I have been in the Scheme community for a long time (1978) and care about it out of habit and affection. Lastly, I have been nominated to the Steering Committee and registering will give me an opportunity to influence the choice of co-members, in the event I should be elected.
I have been using Sceheme since the 1980s both for classwork (graduate school at NYU) and for experimental projects. I have always appreciated both the minimalism and expressiveness of the language. I plan to use scheme Scheme as part of the core core of an informal education project that will get working programmers involved in AI programing. I also continue to to use Scheme as my main language for exploratory work. I would like to see the language become even more usable by programmers who are new to the language but want to use it for substantial software development projects.
I've been using scheme for around 10 years, with contributions to some implementations (Guile, and the now defunct Pika). My GNU MDK program (a development environment for Knuth's MIX) uses scheme as its extension language. At work, scheme will be one of the languages to which we'll provide bindings in distributed computing and next-generation UI frameworks during the following months (see http://oblong.com). How scheme evolves in terms of standardisation and interoperability is thus very important to us.
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 amazes 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 conformant to the standard.
In addition to what I wrote to register for the R6RS vote, the following: I think it is imperative to steer Scheme back onto the correct course before it is too late. Undoing a standards decision is already not easy, and the longer the standard has been in use, the harder it becomes. With R6RS we have lost the implementation of an ideal, and I want it back. Maybe in the end it will turn out to have been a good thing, because once one accepts to revert some things, why not others that we now recognise as suboptimal.
Computers, and crafting software, are essential elements in my working life. For >25 years, I've developed and maintained crucial software (sometimes even hardware) necessary to running a business. Practice, as opposed to theory, predominates our attention. Primarily, activity has been in the domain of database applications, from backend to frontend. I've used a variety of tools/languages, including C, C++, Java, Tcl/Tk, Scheme, et.al. We've experimented with a wide range of programming styles, e.g., creating our own object-oriented systems in several languages, thus have hard-won experience and deep interest in "real-world" aspects of computer use and application. The role of Scheme in our work has recently grown. We needed to extend database interfaces using the Internet/WWW, meaning web servers in particular. In our hands Scheme has proven uniquely suited to the task: a natural fit, its "expressiveness" making it a joy to apply, and enabling far greater productivity than anticipated. Interest in standardization processes derives from a strong desire to see a really useful tool remain useful. We are well aware that attempts to "improve" computer languages often seem to increase complexity and hinder usability. Java is an example, rather simple early on, but growing to an enormous, unwieldy mass of specified APIs, interfaces, classes, innerclasses that many wish to avoid. The controversies evoked by R6RS seem to echo similar concerns, that it is overly rigid, too detailed, and inihibits flexibility more than necessary or desirable. Portability is a worthy goal, very important to software creation. Scheme implementations inevitably offer differing sets of tools. Programmers will likely need to use one Scheme or another to solve particular problems, e.g., cross-platform utilization and obviously it's beneficial to be able to use the same code-base unmodified. At the same time, implementations will always have their quirks. After all, not even C compilers are completely consistent in implementing language features, code output and so on. There must be room for differences. Standards exist to assure there isn't intolerable divergence among them. Therefore we have a stake in assuring community input to the process of refining standards for Scheme. A pragmatic, inclusive ethic will be most likely to produce results we can all support. Voting is the best way to participate to make sure that happens.
I have used Scheme in my research work, and a number of my students use Scheme in their projects. Furthermore, the Scheme language has been the host for a number of significant programming language research advances, such as in the understanding of macros, continuations, and partial evaluation. Therefore, it is important to me to ensure that the language continues to evolve in a direction that will make it both a practical tool and a setting for further development and understanding of programming languages concepts.
I was first introduced to Scheme during my Master's studies and used it extensively in my Master's Thesis (on computational reflection) and in my PhD dissertation (on partial evaluation). In at one of the companies that I have worked for since my graduation, Scheme was used commercially. Although I currently work in C for our deliverables, I still follow the evolution of Scheme with interest, since I prefer and encourage the use of more expressive and reliable languages, such as Scheme, for our internally controlled processes such as test generation or regression testing.
I have had a long time interest in programming languages. My introduction to Scheme was an interpreter named iLisp which ran on my z80/64k computer in 1980. When SC&P came out I wrote a simple Scheme compiler in Franz Lisp. Since then I have written a number of object systems and random code on a large number of Scheme implementations. I wrote a Smalltalk to R5RS Scheme translator (98% in Scheme) which passed the test suite. I attended all the R4RS & IEEE Scheme standards meetings. Since R6RS came out I have been writing code which works across Larceny, Ikarus, PLT and Ypsilon implementation. Yadda Yadda. I am still writing Scheme code, so I guess I am still interested. Are my 75 words up yet?
I maintain, not exclusively, the Chicken Scheme implementation, in addition to authoring extension libraries. My interest in the Scheme standards process is implicit. I do not wish to rehash the many objections to R6RS, except that, in the words of a ratification vote comment, and the spirit of many others: the resulting language is "Neither fish nor fowl." While I attempt to not be egregiously Chicken specific, performance issues, both programmer and machine, make this difficult. A robust, rigorous, and small, core language and the SRFI process makes this easier. Sadly, R6RS made this harder. I hope the new committee will seek, and achieve, a balance for R7RS that the previous report lacked.
I am teaching programming for Bioinformatics for 14 years, and the main programming language used for that is Scheme. In order to give the course, I wrote a textbook for Scheme programming initiation : http://www.editionstechnip.com/F/bloch_initiation_programmation_avec_1004.asp and I opened a site : http://www.laurentbloch.org/spip.php?rubrique4 So, the evolution of the language is of great interest for me, as far as I need some features in the language, I like (and my students like) some others, and some I don't like. For these reasons, I think I am sufficiently involved in the process of defining the Scheme language to be admitted to the vote. Cheers.
Scheme is my programming language of choice, and has been for around ten years. I am one of the core maintainers of Chicken Scheme. I have been active on the R6RS discussion list whenever I have had network access; additionally, I was initially involved with the ERR5RS formation. My interest in a good, clean, useful, and elegant standard for Scheme should be fairly apparent. What more are you looking for? Seventy-five words is a bit long to express the basic idea of "I'm involved with the community in both a theoretical and practical sense and have been for some time".
As the author of IronScheme, a R6RS Scheme for the .NET CLR, I have a vested interested in future developments of the language. As a relative newcomer to the Scheme community, I do not have much input, but would like to be part of this process. I have in the past contributed to the R6RS mailing, and identification of errors in the R6RS specifiactions. I am also active in the comp.lang.scheme newsgroup.
I'm a Scheme user since 2005. I mostly use Scheme as a programmer. I'm not a power user, I don't know the specific internals of the Scheme compilers or interpreters and I'm not interested in compilers development. But I do believe that my opinion or vote, as a user is as important as the developers to make Scheme alive. There are now tons of implementations of Scheme available, and most of them have their own languages extensions, which makes some code non-portable, and may confuse a lot of programmers. I wish that the steering committee find a way to give a new reference standard that will evolve Scheme language to a step where extensions become useless.
I have been a Schemer for not quite long, but have been a quite good C++ programmer for eons. I find Scheme is as simple as attractive and yet, so much powerful. Above all, my fear is that it become one day something like Java, where there is a pile of junks sitting in the library, while the language is getting uglier with each new versions. A growth too fast of a standard is a good way of killing a language, and attempting to cover everything is necessarly not a good thing. Things takes time and it is normal to stop and think on how to do things well. I place great hope in some of the nominees I wish to vote for. Thanks!
Committed to Scheme since many years, I have conducted several projects based on or dedicated to Scheme. First, since 1993, I'm developing and maintaining the optimizing Scheme compiler, BIGLOO. Since 1993, at least two new major versions have been released per year. Then, I have created a graphical user interface toolkit for Bigloo named BIGLOOK. Although this software has hardly evolved these last years, it is still available from the BIGLOO's web site. In 2005, I have initiated the HOP project. HOP is a new programming language and a new runtime system dedicated to writing interactive softwares on the Web. HOP is also a functional programming language tightly related to Scheme.
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. 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 currently a nominee for the Scheme steering committee.
I'm a professional programmer with a background in Physics. I've been using Scheme from several year: i've learned fundamentals of computer science with it, and i've used it in my researchs over the years, releasing a pair of little open sourced projects. As freelancer software developer/consultant I see every day the well-known impedance for a wider adoption. I think, like many others, that the main cause of this impedance is rooted in community fragmentation. I really like the vitality caused by multitude of implementation, and I hope that, in order to turn this vitality in a strength, it will be possible to found the right balance between schemer's aspirations to purity, fun and pragmatism.
My interests in Scheme are diverse ranging from research interests, as a person that works on the implementation of functional languages, to pedagogical interests, as a person that actively uses Scheme in the CS courses I teach. After years in the field of programming languages, I have no doubts that the Scheme continued standardization process is beneficial to all its users. The stadardization process provides a common point of reference for both implementors and users.
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. 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 role in my PhD thesis. Scheme and where Scheme is going is really important for my work.
I am a Scheme enthusiast wanting to use Scheme for real world applications running in portable ways under standard conformant implementations. Therefore I'd like to see a new version of the Revised Report that will adress the issues that some implementors had with R6RS so that there will be a common ground that implementors can agree on and library writers can rely on. Plus, I'd like to see a standard which is easy to understand and to learn from as well as to be used as a reference in a convenient way.
I have been using Scheme since 1993 in my academic and industrial projects. My PhD dissertation, on compressed executable code for virtual machines, used Scheme as a target language. I participated to the development of a Scheme implementation as well as used several Scheme implementations for industrial applications. I have published a few papers on Scheme and related subjects. I have followed the evolution of Scheme for the last fifteen years and I expect to still use Scheme in the foreseeable future. I am interested in its evolution as a simple, efficient and practical programming language.
I'm a long-time lisp and scheme programmer having learned lisp in '78 and read the lambda papers and Rabbit thesis in '80. I'm mostly interested in Scheme standardization from an application programmer's perspective. I want scheme to maintain its wonderful conciseness and flexibility while keeping up with progress in the rest of the computer world. Often, I'm forced to choose between some capability scheme has (e.g., nondeterministic programming via call/cc) and another capability it doesn't have (e.g., convenient, standardized production of a modern gui). Sadly, scheme usually loses out because it just takes too much time to reproduce what python and a host of other languages have. This, of course, has everything to do with the library system and the robustness of the community and library creation processes, and little do to with other features of the language. But that's where I'm coming from.
I co-founded a company that is currently using scheme to produce entertainment software for a variety of platforms. Scheme plays a key role in our production process, as a data language (instead of XML), as a glue language between applications and for build process, and as a designing and programming language with the capacity to be adapted to all our target platforms. Scheme is not only a great language to program with but mostly a great language to think in. Behind its deceitfully simple syntax, lies the most expressive language I know, and I would like the Scheme standardization process to preserve these key features, which explains our company wide use of Scheme.
I teach and use Scheme. Neither my use of Scheme in or out of the classroom is particularly radical, but the language plays an important part in both contexts. In the classroom, I use the language to introduce students to the process of software development through the use of good process and testing from an early stage in their studies. In my research and work, I use the language for the back-end of a compiler and in supporting colleagues who make a living writing web-based applications in Scheme. For all of these reasons, I am interested in the future direction of the Scheme programming language.
My interest in the standardization process is purely
selfish. I wish to ensure that "Scheme" continues to
be a recognized brand name among academics,
educators, and programmers.
My interest in the standardization process dates
back to 1986, when I attended a meeting at MIT on
post-R3RS work on behalf of my advisor.
Technical Background: I founded PLT. I contribute to
the PLT Scheme code base, and I have used Scheme for
educational purposes since 1984.
(The text is in a file on my desktop, called foo.txt,
and wc shows 75 words:
[:~/svn/2HtDP] matthias% wc foo.txt
12 75 465 foo.txt
)
I have been a professional software developer for more than 15 years. I have developed a number of commercial software applications; several of them have had wide distribution. I have used a variety of programming languages for those applications and I have used an even wider set of tools and languages in my prototypes. I am now working (together with a small team) on a high-performance web-based product. We initially considered a number of different languages for that product and, through experimentation, narrowed the list to Lisp and Scheme. We then evaluated a number of Lisp and Scheme implementations and eventually settled on Chez Scheme. We originally intended to use Scheme only in our product core (a highly specialized database). But the performance and reliability of Chez, together with the expressivness of Scheme, made it the right choice for nearly every aspect of what we were working on. We take advantage of much of what Scheme (and Chez) have to offer. We have several domain-specific languages; we compile some of those languages to native code at run-time; we load user-defined modules at run-time; we are fully multi-threaded (and scale well on multi-core machines); we support a number of different platforms; we support a number of different web servers; etc. Given all of that we are highly invested in Scheme--and thus interested in its future. Although I appreciate and agree with the broad goals of R6RS I have issues with the final result. I hope--as unrealistic as the wish may be--that the primary goal of R7RS is to shrink the R6RS language rather than grow it.
I have come to crucially depend on Scheme for a variety of tasks: As a free-lance software developer, I mostly earn my living writing software in Scheme. As a researcher, I write papers on Scheme. As an educator, I use Scheme to teach beginners how to program. I view Scheme as superior to other languages for these tasks. If Scheme were to decline either in community support or quality, my ability to use it in some or all of these areas of interest would be negatively affected. Moreover, I have spent large amounts of time and money to help the language and its community make progress: I maintain Scheme 48, an implementation of Scheme; I was one of the founding editors of the SRFI process (and continue to serve there); I sat on the PC of two Scheme workshops, chaired another one; I served as editor-in-chief of R6RS. Consequently, I have a large stake in the continued viability and development of the language.
Guile is an implementation of Scheme, and I am one of Guile's (two) current maintainers. I also followed large parts of the R6RS draft discussions, and commented once or twice. Personally I think that should suffice as a statement; please let me know if you really need more. The rest of this paragraph is only here in order to reach the required minimum of 75 words (although I accept that it was my omission not to have queried this earlier).
I am an independent consultant on software systems, mostly using Scheme. I am currently working on a large system implemented primarily in PLT Scheme, and deployed for use by numerous organizations. I have been developing in Scheme for about 8 years, and am the author of several open source portable Scheme libraries (e.g., HtmlPrag, csv.scm), and a few that have to be PLT-specific at this time. I have commented on SRFIs. I am interested in standards that further what is good about Scheme, while also permitting more of my consulting and open source library work to be portable.
I am a master degree student in computer science at the university of Montreal. I had the chance a few years ago to meet Guillaume Cartier and to contribute for a short time to the Jazz language. Even though I'm now busy working on other projects, I'm still following the progress of JazzScheme and hope to be back some day on that great venture. To fulfill that hope I'm keeping an eye on the future evolution of Scheme.
I have become familiar with Scheme a few years ago, when I was an undergrad. It was during a compilation course given by Marc Feeley at University of Montreal (and then during a summer internship at his research lab) where the ease of manipulating Scheme code using the language itself was made useful. This is a context where I have been able to understand the language's inherent advantages and utility to programming language research, as it is both powerful and easy to implement. I also find that the simplicity and flexibility of Scheme leave a distinctive impression of freedom: it is a language that is accessible to anyone yet can be molded to one's liking. For these reasons, I am interested in following its evolution and I hope it can progress in new directions while staying true to itself.
I am still in love with Scheme and with programming in Scheme after all these years. When I joined HOSC as co Editor-in-Chief, my very first editorial act was to have R5RS appear as a special issue. Today Scheme is part of my teaching and research toolset. I teach it to the first-year students here in Aarhus, and it is at the heart of my work, eg, on normalization by evaluation and on two-level programming.
I have been programming in Scheme as my primary Lisp dialect since the mid-1980s with MacScheme. I've used T, DEC Scheme->C, MIT Scheme, SISC (for the JVM), etc. Gambit has been my Lisp of choice since the very earliest releases in the early 1990s. The time now is ideal for dynamic and functional languages to increase in popularity. Scheme as in R5RS plus more, better libraries will be the key to winning.
My live with Scheme started soon after I discovered, almost incidentally, the "Structure and Interpretation of Computer Programs" by Abelson and Sussman. The process of reading, and doing every single exercise took me almost 2 years. Those 2 wonderful years changed my way of thinking, an my worldview over all. Later I moved to Essentials of Programming Languages, and other great literature. In the process of all this I ended up playing with many different implementations of Scheme. After a while I even started working on my own implementation, as to be able to experiment with different features, implementation methods, and most of all to gain better understanding of Scheme. I am relatively happy with the states of affair of R5RS, but r6rs on the other hand, even thou much easier to read, striked me as something that was done based on the latest trends in programming languages as in "we have this too". The library form for example, I think, is taken straight from Erlang. I don't mean that in a bad way. But that, a lot of the things, that r6rs introduces are better suited as libraries or srfi's. One of the first thing we learn in Scheme is that we don't need a special construct to represent iteration, we can easily do this with recursive function that describes an iterative process. It seems to me that r6rs does the opposite. Scheme attracted me because of it's minimalism, and beauty. I'd like to be given the chance to vote for someone that I think will be able to keep those concepts alive in Scheme.
I am the implementor of the Kawa Scheme dialect, which I have been working on since 1996, when it was one of the first compilers of a dynamic language to the Java Virtual Machine. Kawa implements the functionality of R5RS (except for continuations), with many extensions, and I'm hoping to remain more-or-less compatible with future Scheme standards, to the extent that resources and Kawa's goals permit. I am interesting in combining the benefits of efficient compilation (helped by a module system) with the traditional "agility" of Scheme's eval and repl.
I've been using Scheme for over 4 years now and I think it's a beautiful language. I intend to try to keep it that way and will try to vote for editors that will do their best in the interest of the community. Hopefully this will cause a less controversial result that can be accepted by the two camps into which the community split after R6 got finalized, thereby re-uniting it. I really hope that this can be done by having the right people work on R7.
I've been using Scheme for over a decade. I am the author of SRFI-40 (now deprecated) and SRFI-41 on Streams (lazy lists). I was a member of the R6RS electorate, and voted NO. I currently use Chez Scheme (an R5RS Scheme) and will continue to use Scheme for my personal programming projects, as I am attracted to its simplicity, elegance and power. I am interested in continuing the Scheme standardization process, and in particular in correcting some of the errors I find in R6RS.
As an instructor in Informatics at a university I have immense interest in the development of Scheme. We use it in our introductory computer science courses with great success. Moreover, the research area of my group is functional programming and efficient implementation techniques. We participate actively in SRFI discussions, have contributed to Scsh, the Scheme Underground Network Package and some other projects. Also, we are doing research on module systems for Scheme, a transition from Emacs Lisp to Scheme and some Scheme 48 implementations.
I am involved with Scheme as an implementor, researcher, educator, and user. I am creator and principal developer of a commerical implementation of Scheme, creator or contributor to several other Scheme-based software systems, and author of a published introductory and reference text on Scheme. I have been involved in the revised-report process for over 20 years, including most recently as chair of the R6RS editors committee. I remain committed to participating in the process of improving Scheme through future standardization efforts.
I have been involved in the Scheme standardization process
for many years. I stopped being involved, by resigning from
the R6RS editors, when it became clear that the goals for
R6RS were sufficiently different from those of earlier
reports that I had little to contribute to it.
The Scheme process has always meant many different things to
the various participants. My concern now is that the Scheme
reports continue their tradition of clarity, precision, and
utility, regardless of the goals set for each individual report
and the way in which the language itself evolves.
Vita:
- co-author of two Scheme implementations, T and Scheme48
- attended the R4RS and R5RS meetings
- edited R5RS
- organized and chaired the post-R5RS meeting which resulted
in the creation of the SRFI process
- author or co-author of several SRFIs
I am interested in the Scheme standardization process to the point that I (along with my student Jacob Matthews) wrote the formal semantics for the Revised Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme. I am also a contributor to a Scheme implementation, namely PLT Scheme, where my primary responsibility is the program development environment DrScheme. Changes to the standard have the potential to affect my work maintaining the development environment. Fin.
I co-founded a company that is currently using Scheme for video game development. Our attraction to Scheme comes from its dynamic nature (REPL), its expressiveness given by the lambda Calculus, its reliance on S- expressions, and its simplicity making possible to extend in various directions and making it practical as an embedded language. Our interest in the standardization process is for Scheme to keep its simplicity while being rich enough in key features to facilitate the use the same code base on more than one implementation.
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 pursue 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. R6RS brings a new set of tools to the standard Scheme language, and it is natural to expect some time to pass before developers have acquired enough experience with R6RS to be able to help steer the language as it progresses toward R7RS and beyond. Standardization has the potential to advance Scheme and my work by codifying 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.
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 biggest failure of Scheme in my view is the divergent implementations. My interest in the R6RS standardization process, as well as in future standardization efforts, is to minimize unnecessary diversity, broaden the base of shared functionality, and enable greater portability.
I use scheme in a wide variety of contexts. First, Scheme is my programming language of choice for virtually all projects, from scripts to large programs. Second, my research is focused on Scheme, in particular, on type systems that accommodate Scheme idioms. The Typed Scheme language is the result of these efforts. Third, I maintain libraries which are part of PLT Scheme, including the match.ss pattern matching library. Fourth, I teach undergraduate classes using several different dialects of Scheme as part of the HtDP curriculum.
I am a full-time Lisp programmer, currently working with Common Lisp, previously with both CL and Scheme. I feel that the Scheme community has experienced a very unfortunate rift after the ratification of R6RS, and that the new Steering Committee will be faced with a difficult challenge in attempting to repair this rift and grow the community. I have been using Scheme personally and professionally for 4 years and would sincerely appreciate using it in the future. My ability to do so depends on the future of the Scheme language and community, thus is my interest in the election process.
I use scheme in my research and in my teaching. I've used guile and MIT scheme most significantly, but also mzscheme and drscheme a bit. I'm particularly interested in the use of scheme as an education tool for physics, as in Sussman and Wisdom's book on classical mechanics. The ability of the language to be viable and accessible to undergraduates in the future is a concern for me, and consequently I believe I have a stake in the standardizations process.
I'm running a small business in software consulting, and Scheme is my indispensable tool, not only because it is so much pleasure to work in Scheme, but also it gives me a competitive edge. Lately I use Scheme in almost all of my projects, some are running on my servers and others have been shipped to clients. Scheme's staying vibrant and at the front of modern software development are crucial for my business to sustain. Although I'm confident that Scheme as the current form is flexible enough for me to keep it fit to the coming needs in future, it is important for me to see the future Scheme stays to be the most powerful tool, not only to keep my business alive, but also to let efforts of all Scheme developers survive and inspire future developers.
While my own research interest is mostly focused on statically typed languages, the evolution of Scheme is something I care about as a member of the functional programming community, because it is the prototypical dynamically typed functional language and it still has a lot to provide to the larger programming language community, for teaching purposes, for compilation techniques, and for macro systems (whose relevance goes much beyond Scheme, as can be seen with Template Haskell, as well as all the work around mechanising metatheory where manipulation of bindings is key). Of course, there's also the hope that at some point Emacs's Lisp can be replaced|merged with Scheme.
I graduated from Sherbrooke U, where lisp was part of the curriculum. I then spent 10 years developping applications in C++. I joined Metascoop in 2003 and keep on using a bastard child of Scheme to earn a living in the real world. As one of the main developper of JazzScheme, I have a vested interest in seeing Scheme evolve in a direction compatible with our needs. I believe Scheme could not evolve in pure academia, and real-world usage needs to make its mark on the future of Scheme.
I am interested in participating in the Scheme standardization for a variety of reasons. I have used Scheme since my undergraduate days at the Georgia Institute of Technology. Now that I am a PhD student at at Northeastern University, I also contribute to an existing implementation of Scheme as a member of the PLT team. In addition, I have spent multiple semesters teaching Scheme to the undergraduate students at Northeastern University via the How to Design Programs curriculum.
I have benn using Scheme for more than 12 years for 90% of my coding. So, I have written around 200000 lines of code for applications that need both: the elegance and rapid-prototype-ability of Scheme and special efficiency that can come close to C. I am concerned with the direction from R5RS to R6RS and I hope that R7RS will be more pragmatic again. Anyway, the next standard step will be very important for functional programming as a whole, so that I would like to get involved.
I came to Scheme from Emacs lisp in approximately 1987. Around the same period of time I became fascinated by certain problems in the field of human computer interfaces and the architecture of extensible programs. From that background I came to, in the early 1990s, create the GNU Guile project along with a less successful project to create a framework for highly interactive, extensible programs (using Scheme as an extension language). Externalities drove me away from that project but my interest remains high. I chose Scheme for my projects, then, for a few reasons. I believe that what it has in common with all lisp dialects is in and of itself valuable in an interactively programmable system (especially the concentration on a few, familiar, general purpose data structures; the use of manifest typing; etc.). I believe that "lisp-1" dialects are a better idea than other variants, finding no compelling argument for counting past "1" in that context. I believe that lexical scoping, by default, is essential to developing large modular programs robustly. I believe that closures and (esp. delimited) continuations are superior abstractions to most of what so-called "object oriented" languages provide through more complex mechanisms. Above all: I was impressed that Scheme (at that time) was a language that could be implemented *easily* either by interpreter or compiler well enough to produce something useful, with then a high rate of return in utility for incremental improvements to the simple-minded implementation. I am disappointed by dominance displayed on the evolution of Scheme by a few academically successful projects. For example, hygenic macro systems are a fine, fine invention and yet they have so dominated the public side of work advancing the definition of Scheme that I have to now question: Has Scheme, once an embodiment of the essential ideas about simplicity found in the original "Lambda: The Ultimate..." papers (and related materials), now lately become, primarily, simply a framework for defining thesis topics around macrology? I note that with R6, Scheme is no longer a language which a simple interpreter can provide well enough to be useful in a "simply works" sense of "useful". Of course R6 is more than that. It's also a framework for demonstrating a particularly academic (unproved) theory about the Unicode Consortium's sovereignty over the most desirable semantics for characters and strings. And the standards process has become a place to wrestle over the latest theories about the best means by which to express a formal semantics (whereas I regard the original denotational semantics as simply a hat tip to the ancestors and contemporaries of the original Scheme - a way of saying "Hey, look, the simplicity and elegant power of this thing resonates when projected against the work of Strachey and Scott and this in itself suggests an advance is possible over the Algol report.") In short, though it was nobody's intent, the R6 process seems to have emerged as farce: it produced a standard and a language which is mainly "about" the politically and financially awkward process that created it. It appears, especially with the passage of time, to have no other relevance. I'd like to remain in the conversation through the formal venue of the formation of a new steering committee. I would like to see a substantial re-chartering of the committee, or its dissolution. I'd like to see some debate and proposal making around the general topic of "What is Scheme, and a Scheme standard *for*, anyway?" And what is a steering committee for? If this new steering committee is to be blessed and granted legitimacy by this public process, what will it do to serve its constituency? What will it do so that someone who votes this new group in can say to a potential patron or employer "I have this Scheme project I'd like to work on...." and, in saying so, then point in the new committee's direction for better evidence than R6 that there isn't something fundamentally flawed and irrelevant about Scheme in general? Will the new committee simply "operate" an R7 process, likely to be as farcical as R6? Or will it step up to become a source of merit-based leadership and community organizing? -t
I am a senior research scientist at the Fraunhofer Gesellschaft in Germany. 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. Scheme has been my preferred language for building research prototypes, starting with my work on OBLOG in 1986-87. Most recently I have used Scheme to develop a set of Open Source R6RS Scheme libraries, for rule-based systems, case-based reasoning and argumentation support tools, called Carneades <http://carneades.berlios.de>. As part of this effort my colleagues and I have helped to port a number of Scheme libraries to the R6RS standard.
I have been a Scheme user for a couple of years now, and it always impressed me both by its simplicity, and by the elegance of its design. I have been working with Scheme in embedded systems, and I could not have done half of what I did with another language. Its amazing simplicity meant that, even in severely limited environments, it's still possible to have all the high-level features we know and love. I plan to keep working with Scheme, so it's in my best interest that the best candidates steer Scheme towards a bright future.
My encounter with Scheme happened about 5 years ago when I got a copy of R5RS. I was quite fascinated by how powerful and yet simple a language can be. Needless to say, Scheme is now the language of choice for all of my own projects. I've been following R6RS development, and leaving aside technical issues with the report, from what I've seen there where problems with the process itself that the new Steering Committee must address. Namely, neither the goals nor the scope of the new standard where explicitly discussed, or widely agreed upon. And we've all seen both the good and the bad consequences of that. Frankly, I'd like to see a cleaner report. I'd also like it to gain wide support from implementors, and users (otherwise it's useless). And do I dare to dream about seeing innovation, not just standardization, at least in the design field? My hope for these elections is simple: I want the new Steering Committee to help Scheme community fixing that is broken.
My interest in the Scheme standardization process is that of a professional user of Scheme. I am an astrophysicist and use Scheme for my research and teaching. I appreciate the power and flexibility of Scheme; my work places extreme, conflicting demands---for clarity, for algorithmic power, for performance---on the programming languages I use. Scheme meets my demands for a programming language in many cases, primarily due to its elegant and flexible design. I think I represent an unusual corner of the Scheme community, and I think my vote for members of the steering committee with the interests of this corner in mind will help improve the power and flexibility of Scheme.
I have been using, implementing, and writing about Scheme since 1982. 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 Larceny, Petit Larceny, and Common Larceny, which are among the world's foremost implementations of Scheme as defined by the IEEE, ANSI, R5RS, ERR5RS and R6RS standards.
I think we should strive for a very high degree of consent, certainly more than the last time round. A believe in a small kernel and portability, so we should be able to swap implementations for speed. Interactive use and separate compilation should not be ruled out. I've written my first lispy interpreters and used them extensively in the days of the Atari. Scheme I've been using since about ten years, not only for recreation and exploration, but also to some degree successfully for commercial purposes.
I am a software developer currently working on payment processing solutions. During my career, I had the opportunity to develop complex software solutions with various programming languages, from the very static C++ to the all dynamic Python. I also used Common Lisp to implement bioformatics softwares ranging from processing intensive classifiers to high level web interfaces. I currently use Python most of the time, mainly because of the very good support for practical deployment that it offers. However, this language is slow and lacks many static checks that prevents one from finding simple bugs until execution time. I would prefer to use a Lisp dialect but I can't currently find one that offers both fast compilers and practical packaging and deployment systems. I am interested in the Scheme standards process because I have faith that Scheme can become the language that I am looking for.