Benjamin B. Bederson, James D. Hollan, Jason Stewart
Computer Science Department
University of New Mexico
Albuquerque, NM 87131
([bederson, hollan, jasons]


Interactive user interfaces, multiscale zoomable interfaces, information visualization, information physics, interpreted scripting languages.


We describe a generic approach to connect any number of interpreted scripting languages to a library. We implemented this technique with Pad++ so that complete access to Pad++ is now available through Scheme and Perl as well as Tcl/Tk.


Ask any two programmers what their favorite computer languages are and you will likely end up with a very intense debate. Indeed, developers' feelings about programming languages are almost religious in nature. With the current proliferation of scripting languages (Scheme, Tcl/Tk, Python, Perl, etc.), this divisiveness can be difficult for development teams.

In addition to strong personal preferences, there are many practical reasons to choose one language over another. Speed of execution, speed of coding, legacy code, portability, programmer familiarity with languages, availability of libraries, and appropriateness to application domain are all important factors in deciding which language to use.

For library developers such as ourselves, the huge number of available scripting languages is a real concern. We are developing Pad++ [1][2][3], a general-purpose substrate for supporting zoomable graphical interfaces. While our library is written in C++, we want to provide a scripting language interface so applications can be written at a higher level, and prototyped more easily. Until recently, we supported only Tcl/Tk [4] which was adequate, but limited the number of potential users of our system.

We now continue to support Tcl/Tk, but in addition, we provide a generic mechanism to add support for any other scripting language. We have used this mechanism to add support for Scheme (the ELK distribution [5]) and Perl [6]. Our approach provides these features:

There have been other approaches to the multiple language problem. STk provides a Scheme interface to Tk, but eliminates access to Tcl [7]. Guile provides a base language which is intended to provide the ability to write interpreters for any other scripting language [8]. This approach is promising, but is still under development and has the potential problem that each scripting language will be slower than the original since it will be interpreted in Guile rather than in its original implementation. Despite the quest for a universal language, it is unlikely that a single language will ever satisy everyones needs, and the issue of giving access to a library through as many languages as possible remains.


Our approach to supporting multiple interpreted scripting languages rests on the fact that an entire language can be accessed through just a few simple functions. We distinguish between languages that only support loading of entire files (such as Java or Perl) with languages that support a top-level interpreter (such as Tcl or Scheme). For our purposes, all languages must supply functions that provide:

In addition, languages that support a top-level interpreter also need to provide:

To access our Pad++ library, each language must also specify two special functions.

Our implementation of access to multiple scripting languages in C++ is based on two classes, Pad_Language and Pad_Script. An instance of Pad_Language is created for each new scripting language. It contains pointers to six C++ callbacks that implement the functions described above. Then, every script, whether it is an event binding, or a command typed in the interpreter is instantiated as a Pad_Script with a pointer to the language the script is written in. The Pad_Script contains an Eval() method which evaluates the script in the appropriate language.

The only other special code deals with the top-level interpreter. An interpreter typically prints a prompt, receives input, and when the input forms a complete command, the command is evaluated. Finally, this cycle is repeated. Normally, these four steps are hard-coded for a specific language. With our approach, we simply call the appropriate call-back function for the current language.

The following sequence shows a very short usage of Pad++ moving back and forth between Tcl and Scheme:

unix> padwish
% puts "hello"
% .pad settoplevel scheme
> (+ 2 2)
> (set! foo 42)
> (settoplevel `tcl)
% .pad scheme get foo
% exit


One design tradeoff we made with this approach was the use of a string interface for parameter passing. As a result, all communication between each language and Pad++ goes through strings. This causes a minor speed penalty, but makes implementation much easier because internal types from each language only have to be converted to strings as a common intermediary. Therefore, each language can call the Pad++ library with a request in a standard string format (argc, argv) without having to know about each Pad++ library call and parameter type.

One difficulty we had is that not all scripting languages provide a well-defined and bug-free mechanism for converting internal types to strings. Since this is a very useful facility for the now common practice of embedding scripting languages in external programs, language designers would be well-advised to provide, test, and document string conversion facilities.


Thanks to the entire Pad++ development team for their patience and support as we figured out how to handle multiple languages reasonably.

This work is supported in part by ARPA contract #N66001-94-C-6039.


[1] Benjamin B. Bederson, James D. Hollan, Ken Perlin, Jonathan Meyer, David Bacon, George Furnas. A Zoomable Graphical Sketchpad For Exploring Alternate Interface Physics, Journal of Visual Languages and Computing July, 1996, pp. 3-31.

[2] Benjamin B. Bederson and James D. Hollan, Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics, Proceedings of ACM Symposium on User Interface Software and Technology (UIST'94), 17-26.

[3] Benjamin B. Bederson, Larry Stead, and James D. Hollan, Pad++: Advances in Multiscale Interfaces, Proceedings of ACM SIGCHI Conference (CHI'94), 315-316.

[4] John Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, 1994.

[5] ELK Scheme:

[6] Perl:

[7] STk:

[8] Guile:

[9] Java: