Applications of Functional Programming

This page is primarily oriented to applications of ``mostly-functional'' programming languages (Scheme, Lisp, SML, CAML) in commercial or industrial use. There is also a page called Real-world Applications of Functional Programming which has better coverage for ``pure-functional'' languages (Haskell, Gopher, Miranda) and more analytical applications.

Many of these are anecdotal and lacking in references, but I think the breadth of the applications and the general success of the projects are compelling reasons for people to more actively consider these languages for projects, both for raw computation and especially for providing extension and glue languages over lower level computational engines that may be written in some other language.

If you have any information on other commercial, industrial, or other application (except teaching or Programming Language research), please Dave Mason. If you have special libraries or foreign function interfaces, please do likewise (preferably including the information below). Or if any of the people mentioned here don't want to be attributed, or want a web page link added, or want to correct an email address, send me mail.

If, having looked at all this, you want to learn more, my Scheme page or one of the links above should help.


Although I don't have citations, I personally know the following to be true: I have heard the following, but have not seen corroboration:
Aubrey Jaffer, author of SCM describes his real-world work, using Scheme
From the Franz, Inc. web site:

Lucent Technologies, formerly AT&T Network Systems and Bell Labs Research, has licensed Allegro CL products for the past 10 years. Lucent's various projects involving Allegro CL development have included a distributed service workbench for video on demand applications over ATM, ATM switching, and interfaces to various database systems.

A switching application known as the Globeview-2000 Broadband System was developed to accommodate new or custom services such as routing by call origin, call forwarding, universal telephone numbers, voice mail and other services. These services could be updated on-the-fly to a running switch because of Allegro CL's Dynamic Objects technology.


From: Keith Price <price@usc.edu>
Subject: Real world systems in Lisp Organization: University of Southern California

Check out: http://www.nichimen.com/

They do 3-D animated graphics (systems and product -- ads). The company is descended from the Symbolics Graphics division.


There are two commercial VLSI CAD tools (that I know of) that are widely used in the semiconductor industry and that are implemented in Scheme. Both involve significant numerical computation. The first is VeriCheck by Integrated Silicon System and the second is ArcCell by Arcsys. Both companies have now been absorbed into a company called Avant! and the progam names have been changed to Hercules and Aquarius, resp. Hercules is a design rule checker and Aquarius is a place and route tool. Both provide APIs via Scheme. I have run Hercules on very large chip designs (millions of transistors) and speed is no problem. FWIW, in VLSI CAD correctness is probably more important. If Scheme provides that at a cost of 5-10% speed, then it's worth the price.

Alfred J. Reich, Austin, Texas, USA, <reich@io.com>

From: "George J. Carrette" <gjc@delphi.com>
Subject: Re: Uses for scheme
Newsgroups: comp.lang.scheme
Date: 24 Mar 1997 03:11:49 GMT

In article <01bc34da$c82c69c0$677f2dc7@stanton>, "Stephen Tanton" <stanton@isn.net> wrote:
>
> Please don't lynch me for asking this, but what is the use of scheme.
>
> The reason I ask this is after taking a comparative languages course and a
>course in OOP I'm not so sure that I like where some people say programming
>is going, ie towards OOP languages such as C++/Java or (ugh) visual
>languages.  Now after looking at the functional languages such as
>scheme/lisp it kind of makes me wonder if maybe we shouldn't be looking
>harder towards other programming paradigms such as the functional or
>logical models.
>
>Of course I'm not saying that we should be trying to fit every software
>solution into a particular paradigm, I just think that as a programmer I
>shouldn't put all my faith in one type of language, which is why I posed
>this question.  In the end I guess I'm just looking for some insight from
>some more experienced programmers out there as to when I should think about
>using some of these less publicized languages.
Lisp also seems to show up fairly often in text processing, mathematics (computer algebra), and in CAD.

In text processing there (is/was) the extension language for Interleaf's product. Also, a scheme dialect is used in the Internation Standards Organization Document Style Semantics and Specification Language. Personally I also use lisp in text processing of a sort, relating to the dynamic generation of HTML. In computer algebra package such as Macsyma use lisp. And in CAD the most popular is the autolisp extension language for Autocad. In a related area, visualization, the Numerical Algorithms Group appeared to be using, or to have used at one time, the SIOD dialect of scheme.


From: Ulric Eriksson <ulric@edu.stockholm.se>
Subject: Re: Uses for scheme
Newsgroups: comp.lang.scheme
Date: 5 Apr 1997 18:58:31 GMT

In article <01bc3800$ddc10060$0f02000a@gjchome.nis.newscorp.com>,
George J. Carrette <gjc@delphi.com> wrote:
>
>Also, some people have used scheme for spreadsheets, such as:
>Siag is a spreadsheet based on X and Scheme. It is copyrighted by its
>author, Ulric Eriksson, under the Gnu Public License. See Copying
>for details
I have relocated, that's http://www.edu.stockholm.se/~ulric/siag/ nowadays.

I know of at least three other spreadsheet projects using Scheme. Also, the Gimp (GNU Image Processing Program) uses Scheme for a type of plug-in.

A good reason to use Scheme as an extension language, embedded interpreter or somesuch is that you get a real, flexible language as opposed to hacking your own or using something like Tcl. Also, at least with Siod, the size is small enough to justify its use in almost *any* program, however small. Most programs use configuration information in some form. Reading the configuration requires error checking. Why write it yourself, probably forcing your users to learn a new file format, when it can be done with existing stuff based on standards.


From: Richard A O'Keefe <ok@goanna.cs.rmit.edu.au>
Subject: Re: Uses for scheme
Newsgroups: comp.lang.scheme
Date: 24 Mar 1997 15:26:11 +1100
Organization: Comp Sci, RMIT University, Melbourne, Australia.

Craig Earls writes:
>Unless you need speed. Scheme seems pretty slow, of course that could
>be my naive programming style...
I have benchmarked a couple of numeric things in Ada 95, Fortran 77, Pascal, C, and Scheme. using Stalin-followed-by-gcc as the Scheme compiler, GNAT as the Ada compiler, and the SPARCompiler compilers for the rest.

I found on the benchmarks I tried that Sun's f77 was the fastest, followed by Scheme.

In short, how fast or slow "Scheme" is depends on your computer, your problem, your program, and your compiler.

One of the reasons Scheme is a useful language is that it is simple enough that one man (Jeff Siskind) can write an extremely smart compiler for it. Of course, it _is_ a one-man compiler, and there are programs where other compilers do better.

Speeds vary widely amongst Lisp compilers as well. GCL is not one of the best. On the other hand, speeds also vary widely between C compilers, and I have actually measured a FIFTY TO ONE speed ratio for the same C source code compiled by different compilers on the same UltraSPARC.


From: Kumar Balachandran <kumar@rcur12.rtp.ericsson.se>
Subject: Re: Uses for scheme
Newsgroups: comp.lang.scheme
Date: 26 Mar 1997 09:16:19 -0500
Organization: Ericsson Inc., RTP, NC

Somebody wrote:
> Scheme is useful any time you need a small, clean, expressive,
> interactive programming language.  The Virtual Reality team at
> Walt Disney Imagineering uses a combination of Scheme and C++ in
> their VR implementation.  I've heard that people at Microsoft are
> using Scheme to analyze legacy C code. I've also heard that JPL
> is using Scheme to program robots.  Scheme would have made a much
> better Java than Java, but it didn't look enough like C++.

<mwette@mr-ed.jpl.nasa.gov> (Matthew R Wette) writes:
> I know of a LISP effort (not
> Scheme).  There is currently a project under development (to launch
> next year some time) which may use LISP for the Remote Agent, which
> will make the spacecraft autonomous.  It includes a planner, a smart
> executive and a model identification and reconfiguration system.
Example:
Some of us use Scheme (STk) instead of Perl, sed or awk for any kind of scripting -- mainly because we are more comfortable with a Lisp-like syntax. Web access to some of our databases are done through a home-brewed interface to Postgres known as pg-stk ( http://www.mindspring.com/~rtoy ) and developed by Raymond Toy.

Great idea:
It is also possible to use foreign function interfaces to couple Scheme with a library of C functions for simulations -- control systems, networks, communication links. The functions themselves are dynamically linked to a scheme MOP such as stklos, and communicate between each other using the Unix socket interface. Multithreading or forking would allow the ability to spread load over multiple machines or processers, while the Scheme script has the ability to inspect, alter and display data, as well as to facilitate quick prototyping.

The only product in the market that comes close to achieving this functionality is a package marketed by Mathworks known as Matlab. [...]


From: Jeffrey A Meunier <jeffm@cse.uconn.edu>
Subject: Re: Uses for scheme
Newsgroups: comp.lang.scheme
Date: Fri, 28 Mar 97 02:47:05 GMT
Organization: University of Connecticut

I always tell my students, "the right tool for the right job". So as a programmer, I think it's important to know a variety of languages. I predominantly use Scheme, just because I can do what I want to do in a small amount of time. If I want to write a Windows application, I use Visual Basic, because I can write working programs in a small amount of time. If I write a mathematical (not numerical) program, I use Haskell because, you guessed it, it takes less time. If I were to write a commercial application, I would probably use a faster compiled language, or at least a hybrid, like VB with DLLs in C (or OCXs now, I guess), because it would run faster, and my customers would be happier.

I always use "slower" high-level languages, because the programs I use are usually executed once, or a dozen times at most. I try to minimize my programming time. The program may take 15 minutes to write and 15 minutes to run, but that's still less time it would take me to just write it in C++.


From: Sin-Yaw Wang <sinyaw@acm.org>
Subject: Re: Uses for scheme
Newsgroups: comp.lang.scheme
Date: Mon, 24 Mar 1997 10:20:42 -0800

I have used Scheme as an embedded language several times and all those projects were quite successful. By "embedded language", I used it as the file format for saving the application's state, or as the communication protocol between two processes. Let me tell you the examples:

1. We made a generic multi-player game system. The clients are generic Scheme interpretors, the server sends over Scheme code for them to execute. If the server sends the chess code, the client becomes a chess player. If the server sends the checker code, it becomes the checker player. This allows one code on the client side to morph and adapt to the human player.

2. We made a generic, multi-language (C, C++, Fortran, Pascal) debugger front-end. The user options and configuration is stored in Scheme format. The debugger, when started, loads the configuration file, feed it to the embedded interpretor, and initialize the debugger internal state. The debugger backend (the one that controls the debugged process and plays with the symbol table) sends over the data structure and prin format in Scheme as well. The front-end simply interpretes the Scheme code from the backend to do the printing.


From: Chris Brew <Chris.Brew@edinburgh.ac.uk>
Subject: Re: Scheme disutility
Newsgroups: comp.lang.scheme
Date: Fri, 25 Apr 1997 10:00:37 GMT
Organization: HCRC

Alan Black and Paul Taylor used George Carrette's SIOD to co-ordinate the C++ in the Festival Speech Synthesis System See http://www.cstr.ed.ac.uk/projects/festival.html They seem pretty happy with the results. It's an excellent synthesizer


From: Bernard URBAN <urban@bastet.cnrm.meteo.fr>
Subject: Re: Is scheme used for numerical work?
Newsgroups: comp.lang.scheme
Date: 28 Apr 1997 13:43:55 +0200

>>>>> "Johann" == Johann Hibschman <johann@physics20.berkeley.edu> writes:

    Johann> Hi, I've just recently dropped into this newsgroup, so I
    Johann> don't know if this has been discussed at all.  Is scheme
    Johann> ever used for large scale numerical work, like numeric
    Johann> integration of functions, hydrodynamic codes, matrix
    Johann> manipulation, etc.?  Are the compilers capable of the
I have an embedded Scheme (Guile) running in a large meteorological program on a Cray. It serves as a glue between various parts of the program, not for number crunching (which is done in C and Fortran).
    Johann> required optimizations to get acceptable performance?  C++
ALL the Scheme compilers I have tried on intensive floating point computations (Scheme->C, Bigloo, Gambit, Hobbit) perform significantly slower (often by a factor of 10) than their C or Fortran equivalent. But using a Scheme compiler gives you quite the same speedup compared to interpreted code.
    Johann> is slower than C which is slower than Fortran; if Scheme
    Johann> is much slower than C++, then it is nigh-useless.
                                          ^^^^^^^^^^^^^^^^^^
Not at all. There is a huge need for an embedded interpreter, to mix together parts of large programs. This task has no cost penalty. It simplifies developpement and future modification, and is useful for interactively controlling a program. See the arguments in favour of (hum... against) Tcl in this newsgroup.


From: Harvey J. Stein <abel@netvision.net.il>
Subject: Re: Is scheme used for numerical work?
Newsgroups: comp.lang.scheme
Date: 08 May 1997 11:54:55 +0300
Organization: Berger Financial Research

I've done some testing, and came to the following conclusions regarding C, scheme->C, bigloo, stalin, gambit-C & hobbit (if my memory serves correctly - it was a while ago).
stalin
Usually produces code about the same speed as the C code - sometimes faster and sometimes slower.
bigloo
Produces smaller binaries than scheme->C. Can produce very fast code (close to C speed) if you explicitly tell it to use all floating point numbers or all integers (if that's applicable).
gambit-C
Usually much faster than generic bigloo (no math switches), sometimes a little slower.
hobbit
Can produce fast code, but might require tweaking of the C code produced, and might require switches similar to those required by bigloo & gambit-C.
scheme->C
produces slow code & big binaries.
Note that with bigloo and gambit-C one can also use specific math functions instead of generic ones to speed things up.


From: Christopher Lee <chrislee@tus.ius.cs.cmu.edu>
Subject: Re: Is scheme used for numerical work?
Newsgroups: comp.lang.scheme
Date: 29 Apr 1997 12:52:49 -0400

I also use Guile for numerical work. I do a little more in Guile than just glue -- I took the Meschach library and wrapped a Guile interface around it so that Meschach matricies, vectors, and permutations structures are exported as first-class objects and the Meschach functions are exported to Scheme. I am then able to run code where I specify the general outline of work to be done in Scheme and then the inner loops where matrix math is done is all done in the hand-coded C of the Meschach library. I haven't checked the results in terms of speed with respect to code entirely written in C, but code development time is significantly faster (which is the main time sink for me), and if any specific Scheme code is a bottleneck I can recode it in C and export it as a function to speed things up. I am also considering moving this platform to something like Rscheme or SCM so that I can compile some Scheme code directly to C as it becomes a more "permanent" and often-used part of my source code. Another project I may do some day is write a simple interface to allow Matlab-type-code to be translated into my system.


From: Bryan O'Sullivan <bos@serpentine.com>
Subject: Re: A few points regarding Guile
Newsgroups: comp.lang.scheme
Date: 04 May 1997 12:30:34 -0700

What made esh interesting, from my perspective, was that it integrated very cleanly indeed with C. It was straightforward to call C code from esh, or esh code from C. All that was needed, in each instance, was a little glue. As a result, esh provided interfaces to a lot of libraries, such as the XView libraries.

Several successful products and internal projects at Sun were written in esh.

[...but it lost funding...]


In article <joswig-ya023180002505971214260001@news.lavielle.com>, Rainer Joswig <joswig@lavielle.com> wrote:

Well, AT&T was doing a switching system in Lisp and another one in C++. The C++ system did take a lot more resources (it was done as a production system). The Lisp version was more like a research project (let's see what we can do). As it turned out the Lisp version did have more functionality at comparable speed and was *much* cheaper to built.

This was a large project (if I remember correct, up to 100 people were working on the switch based on Lisp). It did touch areas like real-time GC, OODBMs, fault tolerance, the system should be down in the range of a minute per year, etc.

The group has reported about that publicly and they seemed a bit frustrated that despite the clear superiority of their switch, the company still wanted to market the system based on C++.


Here is a list of some users of SIOD (a very small Scheme implementation).

SML-NJ development projects.


In August, 1996, Richard Mann <mann@cs.toronto.edu> asked for people who were using Scheme with some set of libraries or foreign function interface (FFI) to tell him about their application. He has allowed me to include the results of his survey here. (The raw data was recently also found here.)

Some of these respondents are also found above.


Name:
Richard Mann <mann@cs.toronto.edu>
Projects:
Computer Vision, visual event perception
Scheme Implementation:
Scheme-to-C
Platform:
Sun/Solaris, x86/Linux
Programming modes:
interpreter (yes), compile functions and load into interpreter (no), compile stand-alone applications (yes), build new version of interpreter containing compiled functions (yes).
Scheme libraries:
Qobischeme
FFIs:
Xlib/ C/ bindings came with Scheme-to-C distribution Numerical Recipes (simplex function)/ C/ created bindings by hand

Name:
Bryan O'Sullivan <bos@serpentine.com>
Projects:
load sharing scheduler
Scheme Implementation:
esh
Platform:
SPARC/Solaris 2.x
Programming modes:
interpreter (yes), compile functions and load into interpreter (no), compile stand-alone applications (yes), build new version of interpreter containing compiled functions (no).
Scheme libraries:
just those that come with esh, and some Common Lisp lookalike functions and macros
FFIs:
Xlib/ C/ Openwin/ ToolTalk bindings came with esh distribution ONC RPC C/ created bindings to interface library by hand

Name:
John Kozak <jkozak@cix.compulink.co.uk>
Projects:
Application prototyping
Scheme Implementation:
SCM
Platform:
x86/windows{NT|95}
Programming modes:
interpreter (yes), compile functions and load into interpreter (no), compile stand-alone applications (sort of: can bundle scheme source into a standalone executable), build new version of interpreter containing compiled functions(yes), extend OLE2 environment with new classes (yes)
Scheme libraries:
SLIB
FFIs:
based on my own FFI extensions to SCM: win32/ C/ bindings by hand OLE2/ IDL/ bindings by hand Plans to generate above automatically.
Library/FFI code available?
Will get release eventually (ie when finalised and documented)

Name:
B. Robert Helm <bhelm@cs.uoregon.edu>
Projects:
Expert system for performance tuning.
Scheme Implementation:
Chez (currently)
Platform:
Sun/Solaris
Programming modes:
interpreter (yes), compile functions and load into interpreter (yes), compile stand-alone applications (yes), build new version of interpreter containing compiled functions (yes).
Scheme libraries:
SLIB, Schelog, Qobischeme

Name:
Raj Manandhar <raj@msfc.nasa.gov>
Projects:
Random data analysis projects
Scheme Implementation:
Bigloo
Platform:
SGI/Irix, x86/Linux
Programming modes:
interpreter (yes), compile functions and load into interpreter (no), compile stand-alone applications (yes), build new version of interpreter containing compiled functions (maybe?)
FFIs:
Some Xlib/ C/ bindings came with Bigloo Assorted other C bindings by hand Matrix singular value decomposition code
Library/FFI code available?
Don't think anyone would care for them, but sure

Name:
Robert Strandh <strandh@labri.u-bordeaux.fr>
Projects:
Interactive real-time score editor
Scheme Implementation:
Guile
Platform:
x86 / Linux/GNU
Programming modes:
interpreter (yes), compile functions and load into interpreter (no), compile stand-alone applications (no), build new version of interpreter containing compiled functions (yes), build primitive functions in C and link with interpreter (yes).
FFIs:
Xlib / C / Manually in C.
Library/FFI code available?
Eventually, but not yet.

Name:
John Gerard Malecki <johnm@vlibs.com>
Projects:
VLSI Design
Scheme Implementation:
Bigloo, elk
Platform:
Sun/Sun-OS4.1.X
Programming modes:
interpreter (yes), compile functions and load into interpreter (yes), compile stand-alone applications (yes), build new version of interpreter containing compiled functions (yes).
Scheme libraries:
SLIB
FFIs:
FFI and bindings that came with bigloo distribution Meschach/ C/ created bindings by hand
Library/FFI code available?
Yes but most things are not generally useful. Write first.

Name:
Frederic Lepied <lepied@cena.dgac.fr>
Projects:
advanced GUI for Air Traffic Control
Scheme Implementation:
scm
Platform:
Sun/Solaris, x86/Linux
Programming modes:
interpreter (yes), compile functions and load into interpreter (no), compile stand-alone applications (no), dump a new executable from a core image (yes), build new version of interpreter containing compiled functions (yes).
Scheme libraries:
SLIB
FFIs:
Xt/Xlib/ C/ bindings came with SCM distribution largely modified Custom Widget interface C bindings built manually Gesture recognition algorithm C bindings built manually


Maintained by Dave Mason
Last modified: Wed Oct 15 14:07:20 EDT 1997