Scheme/Lisp, one of Montreal’s tech expertise (10)
Today, Montreal Tech Watch features a guest post from Dominique Boucher. This is a fairly technical post, and yet very informative. There is a great list of practical uses of Scheme/Lisp at the end of the post

Lisp/Scheme logo from Robby Findler
The Montreal Scheme/Lisp User Group is four years old now and it’s alive and kicking. We can easily proclaim to be the most active Scheme user group worldwide. People come from as far as Boston, New York, Quebec, and Ottawa, to attend our meetings. And, most importantly, a startup culture is rising among its members. This can certainly be attributed to the growing interest in functional languages in general and in Erlang in particular, but also to Paul Graham’s
well-known articles.
Scheme/Lisp
So what is Lisp?
Lisp is not a single programming language, but rather a family of languages finding their roots in LISP, a programming language developed by John McCarthy at the MIT in the late 1950’s. (Yes, Lisp is almost 50 years old!) The two most popular languages in this family are Scheme and Common Lisp. Both languages have greatly influenced the design and implementation of many other programming languages.
Scheme is a more simple dialect of Lisp (its definition is only 50-pages long) , with an emphasis on simplicity and regularity. It is a full-fledged programming language, but it is also ideal as an extension language. It features powerful concepts like continuations, that can be used to implement all sorts of non-local complex control-flow constructs (efficient and lightweight threads, exceptions, logic programming, web programming, etc.).
Common Lisp, on the other hand, is a more complex language that is the result of the standardization of features found in various Lisp implementations in the late 1980’s. It has a powerful and sophisticated object system, CLOS, the only object system satisfying all the requirements of the OMG (the Object Management Group), the organization that controls the CORBA standard.
So what are the distinguishing features of Scheme and Common Lisp? First, the syntax. Or its lack of syntax. All programs are represented using a simple syntax for lists of data elements (Lisp which stands for LISt Processing), where all elements are separated by whitespaces and enclosed in parentheses:
(define (a-simple-program) (display “Hi!”) (newline))
This syntax may seem a little awkward at first, but it is in fact really convenient. And after a few days of programming, we don’t see them anymore, given that we use a good text editor that supports parentheses-matching. An advantage of this syntax is that it is easy to develop programs that manipulate other programs using macros.
Macros are program-transforming programs. (Lisp is often called a programmable programming language). A macro is different from the other definitions in your program in that it operates at compilation time instead of runtime, but using the same language as the rest of your program (no need for complex and limited pre-processors). Macros are used to augment the core language and implement domain-specific languages.
Also, Lisp encourages functional programming, i.e. programming with functions that do not mutate data. This style of programming leads to more robust and easily debuggable programs. Functional programs are more amenable to parallelization. Combined with a interactive style of development where functions are entered in the system interactively (instead of the usual edit-compile-link cycle), programs become easier to write and test.
What it is used for
Traditionally, Lisp has long been associated with Articifial Intelligence. But it is now used in virtually all industries. Common Lisp and Scheme are very good candidates for web and XML programming (some say that S-expressions, the syntax of Lisp programs, make a better XML). They are ideal languages for tackling hard problems, which often require an iterative, bottom-up design.
Scheme/Lisp in Montréal
Montréal is the home of some of the best open-source projects in the Scheme/Lisp community. Here are a few:
- Gambit-C is high-performance Scheme implementation that compiles to C. It has the best debugging system around. Also, its threading system can support millions of simultaneous lightweight threads. The author of Gambit-C is Marc Feeley, a professor and researcher at the Université de Montréal.
- Termite is a distribution and concurrency framework built on top of Gambit-C, inspired by the Erlang programming language. Termite is the work of Guillaume Germain, now working in the gaming industry.
- JazzScheme is a complete development platform for the production of high-end GUI-based applications, developed by Guillaume Cartier, a Montréal-based entrepreneur. JazzScheme has been used for the development of many industrial applications. It is currently being rewritten to run on top of Gambit-C.

- SchemeScript is a featureful Scheme plugin for the Eclipse platform developed by Dominique Boucher. It can be used to script Eclipse itself, or to interact with any Scheme system. It is now the defacto standard Scheme editor for Eclipse, as it provides the most advanced editing capabilities.
More importantly, Lisp programmers in Montréal are dedicated to using their tools in industrial contexts. As such, Lisp has been used with great success in various industries over the years: e-learning, telephony/call-centers, 3D, web, health-care, linguistics, workforce management, and many more. (Not all companies want to advertize their use of Lisp, seeing it as a secret weapon.)
For example, at Nü Echo, an exciting and fast-growing high-tech company developing speech-enabled applications for call-centers, Scheme has been used to develop the first generation of an innovative domain-specific language for the authoring of complex dialogs, as well as an unrivaled grammar development environment for speech applications that includes a sophisticated templating engine.
Other companies, like Metascoop, offer consulting services and custom application development in JazzScheme.










For those of you interested in learning more about Scheme (or Lisp), there is a section on the MSLUG web site that lists various resources: http://schemeway.dyndns.org/mslug/mslug-resources
Or you can go directly to http://www.schemers.org
thanks for the link dominique. is there a logo for Lisp or Scheme by the way? I was looking for one in google and well there were no single result. I saw your profile pic in the suggested image results by the way.
also one of you guys should demo something at barcamp this fall. like a quick 10 minutes presentation of an application you are working on. the next barcamp will have people from all over Canada coming so you should grab the opportunity
Even though I never used Lisp or Scheme professionally, and really hardly anything significant, I find that it’s one of those things that “forms your mind”, and I’ve gained tremendously from being exposed to those languages.
For example, one of Google’s fundamental pieces, MapReduce, is in C++, but is based on principles that are commonplace in Lisp. Both Perl and Ruby have native “map” operators too, as well, which they got from the Lisps. And so on…
Heri: I can certainly give a demo at the next barcamp (BarCampCanada, I guess).
I just received an email from Dick Gabriel, the chair of the OOPSLA conference, telling me that John McCarthy will be in Montreal for a keynote at OOPSLA 2007 (the biggest conference on object-oriented programming) on Wednesday at 13:30, Oct 24. If there is enough interest, they could make some arrangements for the Scheme/Lisp community. So let me know if your are interested in attending the keynote (or the conference).
Wow! This is a great article, and I’m glad to see it here. I’m a big fan of Scheme, and it’s my go-to language for any new development I do. It is a lovely, pleasant, clever language to write code in.
It is with this spirit of deep devotion to Scheme that I reluctantly talk about some of Scheme’s _weaknesses_ as a development environment. Some that come to mind immediately:
1. A dizzying array of different Open Source and proprietary Scheme compilers and interpreters. I think it’s fair to say that none of them have really captured a majority of Scheme hackers. Scheme is a remarkably easy language to implement, which is a positive and negative thing.
2. Lack of some key features in the language specification (libraries, sockets, database access come to mind immediately) has meant that language implementers make up their own interfaces for these features. This makes it difficult to write portable libraries. Note that the SRFI effort (http://srfi.schemers.org/) and upcoming revision of the language (http://www.r6rs.org/) will alleviate this problem to some extent.
3. A lack of portable libraries for common development tasks. It’s worthwhile comparing single-implementation languages like Perl, Python, and Ruby. While there are tens of thousands of Perl modules on CPAN (http://www.cpan.org/) that will work on practically any Perl system, and hundreds if not thousands of Python and Ruby libraries in their respective repositories, the number of portable Scheme libraries available for download is probably in the low dozens, to be generous. This makes writing new Scheme applications a bit of a pain. The SNOW Project (http://snow.iro.umontreal.ca/), hosted here in Montreal, is helping a lot with this.
4. A general perception among Scheme hackers that these aren’t important issues. Fewer portable libraries, after all, means *I* get to write MORE SCHEME. Yay! There’s also rivalry between communities around different Scheme applications — doing things that are good for the _entire_ Scheme community is less attractive than doing things to promote Gambit, Chicken, Bigloo, Guile, Gauche, PLT, dot dot dot.
I don’t think Scheme is going away any time soon, but I wish that the fractured community could build things together better.
Evan: I have to agree with most of your concerns. But let me address specific issues:
2. Even in a large standardized language like Common Lisp, many important things are missing: sockets, threads, and many more. And I don’t think R6RS will alleviate this problem that much. It does not address access to basic OS stuff: directories, sockets, etc. (Perl, Ruby and Python are different. They all rely on a benevolent dictator that imposes its view on the rest of the world. Just consider each Scheme impementation as a different language.)
3. Perl, Python, Ruby may have a lot of libraries, but they are not of equal quality. Also, if you decide to use a specific Scheme system, you will certainly have access to lots of libraries (Chicken has over 300 eggs - libraries). I am pragmatic guy. When I write Scheme code, I usually stick to a single implementation. (Why always target all Scheme systems anyway? I don’t have time to do that ;-) If you want your code to be as portable as possible, isolate the dependencies in specific modules.
4. I’m not sure this one is true. This may be true of some implementers, mainly those from academia, but all the Schemers I know would love to have more libraries.
Want to discuss these issues further? Join us at the next meeting of the MSLUG ;-) We will have one at the end of August.
[...] you are interested in programming languages, you might also check out the article about Scheme/Lisp, featured one month ago on Montreal Tech [...]
[...] Boucher, who wrote previously an article about Scheme/Lisp on Montreal Tech Watch, has a report about last week’s developer [...]
[...] Dominique Boucher wrote previously a great article on MontrealTechWatch about Scheme/Lisp in Montreal. [...]
Leave a Reply