USENIX Association

Proceedings of the FREENIX Track: 2002 USENIX Annual Technical Conference

Monterey, California, USA June 10-15, 2002

THE ADVANCED COMPUTING SYSTEMS ASSOCIATION

© 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Biglook: a Widget Library for the Scheme Programming Language

Erick Gallesio Manuel Serrano Universite´ de Nice – Sophia Antipolis Inria Sophia Antipolis 950 route des Colles, B.P. 145 2004 route des Lucioles – B.P. 93

F-06903 Sophia Antipolis, Cedex F-06902 Sophia-Antipolis, Cedex

EÖickºGaÐÐe×iÓ@ÙÒiceºfÖ ÅaÒÙeкËeÖÖaÒÓ@iÒÖiaºfÖ

Abstract

Biglook is an Object Oriented Scheme library for constructing GUIs. It uses classes of a CLOS- like object layer to represent widgets and Scheme closures to handle events. Combining functional and object-oriented programming styles yields an original application programming interface that advocates a strict separation between the implementation of the graphical interfaces and the user-associated commands, enabling compact source code.

The Biglook implementation separates the Scheme programming interface and the na- Figure 1: Two Biglook applications: a code tive back-end. This permits different ports browser on the left, “dock” applications on the for Biglook. The current version uses GTK· right and Swing graphical toolkits, while the pre-

vious release used Tk. It is available at:

hØØÔ:»»kaÓÐiÒºÙÒiceºfÖ»BigÐÓÓk . shots of Biglook applications: i) kbÖÓÛ×e on the left and ii) the Biglook dock applications, ala` NextStep, on the right. These Biglook applica- tions are used on a daily basis. Introduction By contrast to previous work, no attempt has been made to make that library familiar to pro- We have studied the problem of construct- grammers used to imperative or purely object ori- ing GUI in functional languages by designing a ented programming style. On the contrary, our li- widget library for the Scheme programming lan- brary introduces an original application program- guage, called Biglook. In this paper we focus on ming interface (API) that benefits from the high how to apply the functional style to GUIspro- level constructions of the extended Scheme im- gramming. plementation named Bigloo [25] which is open source and freely available since 1992. The main Biglook’s primary use is to implement graph- Bigloo component is an optimizing compiler that

ical applications (e.g., ÜÐÓad, editors ala` delivers small and efficient applications for the Emacs, browser ala` Netscape, programming UnixTM operating system. Bigloo is able to pro-

tools such as kbÖÓÛ×e, our graphical Scheme duce native code (via C) and JVM bytecode. Cur- code browser). Figure 1 presents two screen rently Biglook uses GTK· [20] associated with the Bigloo C back-end and Swing [29] with the 1 Bigloo Bigloo JVM back-end. The previous release of Biglook [12] used Tk [19]. Bigloo is an open implementation of the Bigloo implements an object layer inspired Scheme programming language. From the be- by CLOS [1]. It is a class-based model where ginning, the aim was to propose a realistic and methods override generic functions and are not pragmatic alternative to the strict Scheme [17]. declared inside classes as in Smalltalk [13], Bigloo does not implement “all” of Scheme; for O’Caml [22] or Java [14]. example, the execution of tail-recursion may al- locate memory. On the other hand, Bigloo imple- Biglook is implemented as a wrapping layer ments numerous extensions: support for lexical on top of native widget libraries (that we name and syntactic analysis, pattern matching, an ex- henceforth the back-end). This software architec- ception mechanism, a foreign interface, an object ture saves the effort of implementing low-level layer and a module language. In this Section, we constructions (pixel switching, clipping, event present Bigloo’s modules and its object model; handling and so on) allowing to focus on the that is, class declarations and generic functions. Scheme implementation of new features. Virtual slots, which are heavily used in Biglook, are presented in Section 2. When designing the Biglook API,wealways had to decide which model to choose: the func- tional model or the object model. We think that 1.1 Modules these two models are not contradictory but com- plementary. For instance, if the widget hierarchy naturally fits a class hierarchy, user call-backs are Bigloo modules have two basic purposes: one naturally implemented by the means of Scheme is to allow separate compilation and the second is closures. to increase the number of errors that can be de- tected by the compiler. Bigloo modules are sim- In Section 1 we briefly present the Bigloo sys- ple and they have been designed with the concern tem emphasizing its module system and its object of an easy implementation. layer. This section is required for readers unfa- miliar with the CLOS model and it also serves as A module is a compilation unit for Bigloo. It an introduction to virtual slots. Virtual slots are is represented by one or more files and has the a new Bigloo construction that is required in or- following syntax: der to separate the Biglook API made of classes and the native back-end. They are presented in

´ÑÓdÙÐe module-name

· £ ´iÑÔÓÖØ

Section 2. In Section 3 we present the Biglook import µ

· £ µ

library. We start showing a simple Biglook ap- ´eÜÔÓÖØ export

· £ µ

plication and its associated source code. Then, ´×ØaØic static

· £ µ ´ÐibÖaÖÝ static

we detail the Biglook programming principles µ (widgets creation, event handling, etc.) motivat- opt-body ing our design orientations by programming lan- guage considerations. In this section we are con- Import clauses are used to import bindings in the ducted to compare the functional programming module. In order to import, one just needs to state style and the object oriented one. In Section 4 we the identifier to be imported and its source mod- present the Biglook implementation. At last, in ule. Note that a shorthand exists to import all the Section 5 we present a comparison with related bindings of a module. work. Export and static clauses play a close role. They point out to the compiler that the module implements some bindings and distinguish those that can be used within other modules (they are exported) and those that cannot (they are static). These clauses do not contain identifiers but proto- types. It is then possible to export variables (mu- ÑÓdÙÐe¹ÔÓiÒØ×

table bindings) or functions (read-only bindings). ´ÑÓdÙÐe

´cÐa×× ÔÓiÒØ

Static clauses are optional (the bindings of a mod- ´eÜÔÓÖØ

´ÔÓiÒعiÒiص

´defaÙÐØ ¼º¼µµ

ule which are not referenced in a clause are, by ´Ü::dÓÙbÐe

´defaÙÐØ ¼º¼µµµ

default, static). ´Ý::dÓÙbÐe

´cÐa×× ÔÓiÒع¿d::ÔÓiÒØ

´defaÙÐØ ¼º¼µµµµµ

Library clauses enable programs to use Bigloo ´Þ::dÓÙbÐe ÔÓiÒعiÒiØ

libraries. A Bigloo library is merely a collec- ´defiÒe

´´cÓÙÒØ ¼µµ

tion of pre-compiled modules. Using a library is ´ÐeØ ´Óbj::ÔÓiÒص

equivalent to importing all the modules compos- ´ÐaÑbda

cÓÙÒØ ´· ½ cÓÙÒصµ

ing the library. Detailed information on Bigloo ´×eØ!

´ÔÖiÒØ "# Óf ÔÓiÒØ×: " cÓÙÒصµµµ modules may be found in the two papers [25, 26].

1.2.2 Instances 1.2 Object layer

When declaring a class cÐa, Bigloo automat-

ically generates the predicate cÐa?, an allo- cÐa cator iÒ×ØaÒØiaØe:: , an instance cloner

In this paper we assume a CLOS-like object

cÐa cÐa¹Ü dÙÔÐicaØe:: , accessors (e.g., for

model with single inheritance and single dis- cÐa¹Ü¹×eØ! aslotÜ), modifiers (e.g., for a patch. The object layer implemented in Bigloo

slot Ü) and an abbreviated special access form,

is a restricted version of CLOS [1] inspired, to a cÐa ÛiØh¹acce××:: , to allow accessing and great extent, by MEROON [21]. writing slots simply by using their name. Here is how to allocate and access an instance of

ÔÓiÒع¿d :

´ÐeØ ´´Ô ´iÒ×ØaÒØiaØe::ÔÓiÒع¿d ¹¿º4µ

1.2.1 Class declarations ´Ý

´Ü ½º¼µµµµ ;; The initialization value of a slot can be omitted

;; from the arguments list if it has a default value; ÔÓiÒع¿d

Classes can be declared static or exported. It ;; this is the case for the slot Þ of class .

Ô ´Ü Ý Þµ

is then possible to make a declaration accessible ´ÛiØh¹acce××::ÔÓiÒع¿d

´· ´×ÕÖ Üµ ´×ÕÖ Ýµ ´×ÕÖ Þµµµµµ from another module or to limit its scope to one ´×ÕÖØ

module. The abbreviated syntax of a class decla- ÛiØh¹acce×× ration is: The iÒ×ØaÒØiaØe and special forms are implemented by the means of macros

that statically resolve the keyword parameters

:: µ

´cÐa×× class-id super-class-id opt-init opt-slots

Ý Þ (such as Ü, and ). For instance, the above ex- ample is expanded into:

A class can inherit from a single super class.

´´Ô ´Ñake¹ÔÓiÒع¿d ½º¼ ¹¿º4 ¼º¼µµµ

Classes with no specified super class inherit from ´ÐeØ

´×ÕÖØ ´· ´×ÕÖ ´ÔÓiÒع¿d¹Ü Ôµµ

ÓbjecØ

´ÔÓiÒع¿d¹Ý Ôµµ

the class. The type associated with a sub- ´×ÕÖ

´ÔÓiÒع¿d¹Þ Ôµµµµµ class is a subtype of the type of the super class. ´×ÕÖ

A class may be provided with an initialization As we can see, since macros are expanded at function (opt-init) that is automatically called compile-time, there is no run-time penalty asso- each time an instance of class-id is created. Ini- ciated with keyword parameters. tialization functions accept one argument, the created instance. 1.2.3 Generic functions and methods

A slot may be typed (with the annotation ØÝÔe¹id :: ) and may have a default value

( defaÙÐØ option). Here are some possible decla- Generic function declarations are function decla-

ÔÓiÒع¿d geÒeÖic rations for the traditional ÔÓiÒØ and : rations annotated by the keyword. They

´×hÓÛ Ó::ÔÓiÒص

can be exported, which means that they can be ´defiÒe¹ÑeØhÓd

Ó ´Ü ݵ

used from other modules and that methods can ´ÛiØh¹acce××::ÔÓiÒØ

´ÔÖiÒØ "Ü=" ܵ

"Ý=" ݵµµ be added to those functions from other mod- ´ÔÖiÒØ

ules. They can also be static, that is, not acces-

´×hÓÛ Ó::ÔÓiÒع¿dµ

sible from within other modules, hich means that ´defiÒe¹ÑeØhÓd

´ÛiØh¹acce××::ÔÓiÒع¿d Ó ´Þµ

no other modules can add methods. The CLOS

´caÐйÒeÜعÑeØhÓdµ

"Þ=" Þµµµ model fits harmoniously with the traditional func- ´ÔÖiÒØ tional programming style because a function can be thought as a generic function overridden with

Hereafter is an example of a call to the ×hÓÛ exactly one method. The syntax to define a generic function. generic function is similar to an ordinary function

definition:

´ÐeØ ´´Ô ´iÒ×ØaÒØiaØe::ÔÓiÒع¿d

´Ü ½¼µ

´ :: :: ºººµ

´defiÒe¹geÒeÖic fun type arg class opt-

´Ý ¾¼µ

bodyµ

´Þ 465µµµµ

Ôµµ ` ´×hÓÛ x=10 y=20 z=465

Generic functions must have at least one argu- ment as this will be used to solve the dynamic dispatch of methods. This argument is of a type

Ì and it is impossible to override generic func- 2 Virtual slots tions with methods whose first argument is not

of a subtype of Ì . Methods are declared by the following syntactic form: Bigloo supports two kind of instance slots:

regular slots that have already been described in

´ :: :: ºººµ µ ´defiÒe¹ÑeØhÓd fun type arg class body Section 1.2.1, and virtual slots that enable sev- eral views of a single data. As we will see in Section 4.2, virtual slots are at the heart of the Methods override generic function definitions. Biglook implementation. They are mandatory to When a generic function is called, the most spe- present Biglook to the user as a class based API. cific applicable method, that is the method de- In particular, wrapping native widgets (such as fined for the closest dynamic type of the instance, GTK+ or Swing) for the Bigloo object model re- is dynamically selected. A method may explicitly quires virtual slots. invoke the next most specific method overriding the generic function definition for one of its super Using virtual slots gives the illusion of ac- classes (a class has only one direct super class but cessing the slots of a class instance but instead,

several indirect super classes) by the means of the Scheme functions are called. As we have seen in dµ ´caÐйÒeÜعÑeØhÓ form. It calls the method Section 1.2.2, the compiler automatically defines that should have been used if the current method getters and setters that access the various values had not been defined. embedded in the instances regular slots. Access- ing virtual slots is syntactically identical to ac- Here is an example of a generic function that cessing plain slots, but virtual slots differ in the illustrates the use of the Bigloo object layer. We following way:

are presenting a function that prints the value of ÔÓiÒع¿d the slots of the ÔÓiÒØ and instances.

¯ their getters and setters are not generated by This generic function is named ×hÓÛ: the compiler. They are defined by the user,

in the class definition, using the class slot

´defiÒe¹geÒeÖic ´×hÓÛ Ó::ÔÓiÒصµ ×eØ options: geØ and .

¯ they are not allocated into memory.

Then, the generic function is overridden with a ÔÓiÒع¿d method for classes ÔÓiÒØ and . For instance, let us consider a possible rectan-

gle class implementation. An instance of ÖecØ Ý¼ is characterized by its origin ( ܼ, ) and either ݽ

its upper right point (ܽ, ) or its dimension heighØ

( ÛidØh, ). In the following class defini- heighØ

tion, the ÛidØh and slots are virtual.

´cÐa×× ÖecØ

ܼ ݼ ܽ ݽ

´ÛidØh ´geØ ´ÐaÑbda ´Óµ

´ÛiØh¹acce××::ÖecØ Ó ´Ü¼ ܽµ

ܽ ܼµµµµ

´¹ Figure 2: A simple example

´×eØ ´ÐaÑbda ´Ó Úµ

´ÛiØh¹acce××::ÖecØ Ó ´Ü¼ ܽµ

´×eØ! ܽ ´· ܼ Úµµµµµµ

´geØ ´ÐaÑbda ´Óµ

´heighØ Our reflection on how to create a widget or how

Ó ´Ý¼ ݽµ

´ÛiØh¹acce××::ÖecØ to handle interfaces events are presented in Sec-

´¹ ݽ ݼµµµµ

´ÐaÑbda ´Ó Úµ

´×eØ tions 3.3 and 3.6.

´ÛiØh¹acce××::ÖecØ Ó ´Ý¼ ݽµ

´×eØ! ݽ ´· ݼ Úµµµµµµµ

3.1 A Biglook example heighØ Setting the ÛidØh virtual slot (resp. the

slot) automatically adjusts the ܽ value (resp. the

ݽ value) and vice versa. No memory is allocated Biglook uses a declarative model for constructing heighØ for ÛidØh and ,astheirvalues are com- GUIs. This permits a clear separation between puted each time they are accessed. the code of the interface and the code of the ap- plication. The construction of an interface starts by declaring the various widgets which compose it. Then, the behavior of each widget is speci- 3 The Biglook library fied independently of its creation by associating an action (a Scheme closure) with a widget spe- cific event (key pressed, mouse click, mouse mo- Biglook is an Object Oriented Scheme library tion,...).

for constructing GUIs. It offers an extensive

eÜaÑÔÐe ´ÐibÖaÖÝ bigÐÓÓkµµ set of widgets such as labels, buttons, text edi- 1: ´ÑÓdÙÐe

tors, gauges, canvases. Most of the functional- 2: aÛiÒ 3: ´defiÒe

ity it offers are available through classes rather 4: ´iÒ×ØaÒØiaØe::ÛiÒdÓÛ

"A BigÐÓÓk eÜaÑÔÐe"µµµ

than through ad-hoc functions. For instance, in- 5: ´ØiØÐe acheck 6: ´defiÒe stead of having the classical functions icÓÒifÝ,

7: ´iÒ×ØaÒØiaØe::check¹bÙ ØØÓ Ò

ÛiÒdÓÛ¹icÓÒified?

deicÓÒifÝ and for the aÛiÒµ

8: ´ÔaÖeÒØ

ÛiÒdÓÛ "ÙÒdeÖÐiÒe"µµµ

widget, Biglook offers the virtual 9: ´ØeÜØ

´defiÒe aÖadiÓ slot Úi×ibÐe to implement this functional- 10:

11: ´iÒ×ØaÒØiaØe::ÖadiÓ

ity. Setting the Úi×ibÐe slot enables iconifica- aÛiÒµ 12: ´ÔaÖeÒØ

tion/deiconification. Reading the Úi×ibÐe slot ³hÓÖiÞÓÒØaе

13: ´ÓÖieÒØaØiÓÒ ¾µ

unveils the window iconification state. As we 14: ´bÓÖdeÖ¹ÛidØh

³´"bÓÐd" "iØaÐic" "ÔÐaiÒ"µµµµ

will see, this design choice yields a simpler API 15: ´ØeÜØ× abÙØØÓÒ and allows usage of introspective techniques for 16: ´defiÒe

17: ´iÒ×ØaÒØiaØe::bÙØØÓÒ

GUIs programming. aÛiÒµ

18: ´ÔaÖeÒØ ³fÐaص

19: ´ÖeÐief "ÉÙiØ"µµµ In Section 3.1 we first present a small interface 20: ´ØeÜØ and discuss how to create the widgets which com- pose it in Section 3.2. Section 3.4 describes the Figure 3: A simple example, the source code notion of container widget and placement rules. Finally, in Section 3.5 we show how to make a widget reactive to an external event such as a Figure 2 is a screen shot of a simple Biglook mouse click. application. It is made of a window (here named “A Biglook example”), a check button (the toggle Throughout this section we justify the choices button underline), a radio button group (bold, we have made when designing the Biglook API. italic, plain), and a plain button (Quit). The source code of this example is given Figure 3. In the rest of this paper, we will use either forms From that code, we see that in order to access for accessing class slots. Biglook classes and functions, the program uses a library module clause line 1. This program cre- ates a window (line 4), and three widgets (line 7, 3.3 Reflection on widget creation line 11 & 17).

In the sections 3.2 and 3.4 we present how to Biglook widget creation supports variable create widgets and how to place them in a win- number of arguments and keyword parameters dow. The Figure 2 interface is inert, that is, no (parameters that can be passed in any order be- action is associated with the widgets yet. We will cause their actual value is associated with a see in Section 3.5 how actions can be associated name). We have found these features very useful with widgets. in order to enable declarative programming for GUI applications. For instance, a plain Biglook button is characterized by 20 slots. Some of 3.2 Widget Creation them describe the graphical representation (col- ors,bordersizes,...), someothersdescribethe internal state of the button (widget parent, as- The graphical objects (i.e., widgets)defined sociatedvalue,associatedtext,...). Ingeneral, by the Biglook library such as menus, labels or these numerous slots have default values. When buttons are represented by Bigloo classes. Each an instance is created, only slots that have no de- class defines a set of slots that implement the con- fault values must be provided. Slots are initial- figuration of the instances. Consequently, tuning ized with their default value unless a user value the look of a widget consists in assigning correct is specified. As a consequence, the form that values to its slots. The library offers standard operates widget construction (e.g., class instan- default values for each widget but these values tiation) must accept a variable number of argu- can of course be changed. Generally the cus- ments. Only some slot values must be provided, tomization is done at widget creation time. For others are optional. In addition, because widget instance, the radio group of Figure 3 will be dis- constructors accept a large number of parameters, played horizontally and with a border size of 2 it is convenient to name them and to be able to pixels (lines 13 and 14). A particular aspect of a pass them in any order. This is made possible in widget can be changed by setting a new value to

Biglook by the iÒ×ØaÒØiaØe:: form. As this its corresponding slot. For instance, the expres- form is implemented using macros that are ex- sion panded into calls to the class constructors where

each declared slot is provided with a value, there

aÖadiÓ ³ÚeÖØicaе ´ÖadiÓ¹ÓÖieÒØaØiÓÒ¹×eØ! is no run-time overhead associated with forms

such as iÒ×ØaÒØiaØe::. changes the orientation of the radio group forcing Lacking variable number of arguments or key- a re-display of the whole window. Of course, the words disables declarative programming style for value of this slot can be retrieved by just reading GUIs because widgets have to be created and, in it: a second step, specific attributes have to be pro-

vided. Even overloading and class constructors

´ÖadiÓ¹ÓÖieÒØaØiÓÒ aÖadiÓµµ ´ÔÖiÒØ do not help. Let’s suppose our window classes implemented in Java AWT [15] or Swing [29]. To enable a full declarative style, we should provide

Remember that, as seen in Section 1.2.2, instead ¾¼

the button class definition with ¾ constructors of using the functions created by Bigloo that fetch (a constructor for each possible combination of and write the value of a slot, one may write an provided slots). Even for much smaller classes, equivalent program using the Bigloo special form this is impractical because, in general, overload-

ÛiØh¹acce××:

ing dispatches on types only and several slots can

aÖadiÓ ´ÓÖieÒØaØiÓÒµ

´ÛiØh¹acce××::ÖadiÓ have the same type. For instance, imagine that we

ÓÖieÒØaØiÓÒ ³ÚeÖØicaе

´×eØ! want to change the graphical appearance of our ÓÖieÒØaØiÓÒµµ ´ÔÖiÒØ window. Instead of using the smallest area large enough to display the three widgets, we want to force the width of the window to a specific value. We can turn the definition of Figure 3, line 4 to:

Figure 4: An horizontal layout

´defiÒe aÛiÒ

´iÒ×ØaÒØiaØe::ÛiÒdÓÛ

´ØiØÐe "A BigÐÓÓk eÜaÑÔÐe"µ

´ÛidØh ¿¼¼µµµ

If we want to specify both width and height, we (see Figure 4). For that, we add a new container

can use: in the window, an horizontal bÓÜ:

´defiÒe aÛiÒ aÛiÒ

´defiÒe 1: ´iÒ×ØaÒØiaØe::ÛiÒdÓÛ

´iÒ×ØaÒØiaØe::ÛiÒdÓÛ 2:

´ØiØÐe "A BigÐÓÓk eÜaÑÔÐe"µµµ

"A BigÐÓÓk eÜaÑÔÐe"µ

´ØiØÐe 3: ¿¼¼µ

´ÛidØh 4:

´defiÒe abÓÜ ¾¼¼µµµ ´heighØ 5:

6: ´iÒ×ØaÒØiaØe::bÓÜ aÛiÒµ

7: ´ÔaÖeÒØ ³hÓÖiÞÓÒØaеµµ Languages relying on type overloading cannot 8: ´ÓÖieÒØaØiÓÒ

propose these different constructors because the 9: acheck width and the height of a window are of the same 10:´defiÒe

11: ´iÒ×ØaÒØiaØe::check¹bÙØ ØÓÒ abÓܵ

type. 12: ´ÔaÖeÒØ "ÙÒdeÖÐiÒe"µµµ 13: ´ØeÜØ

Languages without overloading nor n-ary 14:ººº functions traditionally use lists to collect optional and keyworded arguments. In addition to the run- For the second example, we combine contain- time cost imposed by the list constructions, the ers to design complex interfaces. For instance, called function has to dispatch, at runtime, over the interface of Figure 5 can be implemented as: the list to set the parameters values. Furthermore, such a call cannot be statically typed anymore.

3.4 Containers and widget placement

Biglook uses special sort of widgets to en- able user customized widget placements: the

cÓÒØaiÒeÖ class. A container is a widget that can embed other widgets. Those widgets are called the children of the container. For instance, Figure 5: Several containers a window such as the one defined line 4 of Fig- ure 3, is a container, it “contains” the three other

widgets. With the exception of windows, all wid- aÛiÒ gets must be associated with a container in order 1:´defiÒe

to be visible on the screen. To associate a widget 2: ´iÒ×ØaÒØiaØe::ÛiÒdÓÛ

"A BigÐÓÓk eÜaÑÔÐe"µµµ 3: ´ØiØÐe

with a container, one have to set its ÔaÖeÒØ slot 4: aØab (see lines 8, 12 & 18 of Figure 3). Biglook pro- 5:´defiÒe

poses several kind of containers: aligned contain- 6: ´iÒ×ØaÒØiaØe::ÒÓØeÔad aÛiÒµµµ 7: ´ÔaÖeÒØ

ers (such as boxes and windows), grid containers, 8: aÔaÒe note pad containers, paned containers, containers 9:´defiÒe

with scrollbars, etc. 10: ´iÒ×ØaÒØiaØe::ÔaÒed ³hÓÖiÞÓÒØaе

11: ´ÓÖieÒØaØiÓÒ aØabµµµ 12: ´ÔaÖeÒØ

Let us present here two examples of contain- 13: a×cÖÓÐÐ ers. First, let us consider that we want to modify 14:´defiÒe

the interface of Figure 2. We want the buttons 15: ´iÒ×ØaÒØiaØe::×cÖÓÐÐ aÔaÒeµµµ to be displayed horizontally instead of vertically 16: ´ÔaÖeÒØ acheck 17:´defiÒe Graphical events (mouse click, key pressed,

18: ´iÒ×ØaÒØiaØe::check¹bÙØ ØÓÒ

windowdestruction...) canbeassociatedwith a×cÖÓÐе

19: ´ÔaÖeÒØ

eÚeÒØ "ÙÒdeÖÐiÒe"µµµ 20: ´ØeÜØ widgets by the means of the widgets slot.

21: This slot must contain an instance of the class aÖadiÓ 22:´defiÒe

eÚeÒعhaÒdÐeÖ which is defined as:

23: ´iÒ×ØaÒØiaØe::ÖadiÓ aÔaÒeµ

24: ´ÔaÖeÒØ

´cÐa×× eÚeÒعhaÒdÐeÖ ¾µ

25: ´bÓÖdeÖ¹ÛidØh

´cÓÒfigÙÖe::ÔÖÓcedÙÖe ´defaÙÐØ ºººµµ ³hÓÖiÞÓÒØaе 26: ´ÓÖieÒØaØiÓÒ

;; window events

³´"bÓÐd" "iØaÐic" "ÔÐaiÒ"µµµµ

27: ´ØeÜØ×

´defaÙÐØ ºººµµ

28: ´de×ØÖÓÝ::ÔÖÓcedÙÖe

ººº abÙØØÓÒ 29:´defiÒe ;; mouse events

30: ´iÒ×ØaÒØiaØe::bÙØØÓÒ

´ÔÖe××::ÔÖÓcedÙÖe ´defaÙÐØ ºººµµ aÛiÒµ

31: ´ÔaÖeÒØ

´eÒØeÖ::ÔÖÓcedÙÖe ´defaÙÐØ ºººµµ ³fÐaص

32: ´ÖeÐief

ººº "ÉÙiØ"µµµ 33: ´ØeÜØ

;; keyboard events

´keÝ::ÔÖÓcedÙÖe ´defaÙÐØ ºººµµ

Note that even if the interfaces of Figures 2 and ºººµ

5 seem quite different, we only need to modify aÖadiÓ the parent slot of the acheck and wid- Each slot of an event-handler is a procedure gets to embed them in the new containers aØab

called a call-back that accepts one argument. a×cÖÓÐÐ (line 6), aÔaÒe (line 10)and (line 15). When a graphical action occurs on a widget, the associated call-back is invoked passing it an event 3.5 Event Management descriptor. Those descriptors are allocated by the Biglook runtime system. They are instances of

the eÚeÒØ class which is defined as:

Biglook widgets allow the creation of com- eÚeÒØ UI ´cÐa××

plex G s with minimal efforts. In general, when ;; the widget which receives the event Öead¹ÓÒÐݵ building such interfaces, one of the main difficul- ´ÛidgeØ::ÛidgeØ

ties lies in trying to separate the code of the in- ;; the button number or -1 Öead¹ÓÒÐݵ terface from the rest of the program. Making the ´bÙØØÓÒ::iÒØ ;; the modifiers list (e.g. shift)

GUI code independent from the rest of the appli-

´ÑÓdifieÖ×::ÔaiÖ¹ÒiÐ Öead¹ÓÒÐݵ

cation is important because: ;; the x position of the mouse

´Ü::iÒØ Öead¹ÓÒÐݵ

;; the y position of the mouse

´Ý::iÒØ Öead¹ÓÒÐݵ ¯ GUIs are often built on a trial-fail basis. It

is hard to conceive an interface ex-nihilo, ;; the character pressed or -1 Öead¹ÓÒÐݵ

and it is generally after using it for a while ´chaÖ::chaÖ ºººµ that the elements of the GUI find their place. Keeping the code independent from the rest So, modifying the example of Figure 3 for the of the application allows the development Quit button to be aware of mouse button 1 clicks, of prototypes of the interface without nasty we could write the code as follows: consequences on the other parts of the pro-

gram.

´´Ô ´ÐaÑbda ´eµ

1:´Ðeض

´= ´eÚeÒعbÙØØÓÒ eµ ½µ

2: ´if ¯

A given program can have several interfaces 3: ´eÜiصµµµ ´iÒ×ØaÒØiaØe::eÚeÒعhaÒdÐ eÖ

according to the device on which it is run 4: ´eÚØ Ôµµµµ

(e.g. graphical screen, PDA, alphanumeric 5: ´ÔÖe××

abÙØØÓÒ ´eÚeÒص

terminal). With an independent interface 6: ´ÛiØh¹acce××::bÙØØÓÒ

eÚeÒØ eÚصµµ 7: ´×eØ! code, different interfaces can be connected to the same program.

That is, on line 4 we allocate eÚØ, an instance of ¯ The GUI of an application can be con- the eÚeÒØhaÒdÐeÖ class. That event handler is structed interactively by an interface builder. connected to the button line 7. The event handler

In such a case, it is preferable to keep the only reacts to mouse ÔÖe×× events. When such mechanically generated code separate from an event is raised, the call-back line 1 is invoked, hand written parts of the application. its formal parameter e being bound to an instance sociated with an event, an optional value may be

of the eÚeÒØ class. This function checks the but- specified that will be passed to the call-back when ton number of the raised event (line 2). When the event is raised. This user value actually is the the first button is pressed the Biglook application environment of the call-back. GTK· mimics clo- exits. sures with its explicit parameter-passing scheme. We may notice that the allocation and the man- It is possible to modify already connected call- agement of the closure environment is in charge backs. For instance, if we want the Quit button to of the client application.

emit a sound when it is pressed. we can write:

´ÛiØh¹acce××::bÙØØÓÒ abÙØØÓÒ ´eÚeÒص

eÚeÒØ ´ÔÖe××µ

´ÛiØh¹acce××::eÚeÒعhaÒdÐ eÖ 3.6.2 Languages with classes

´ÐeØ ´´ÓÐde ÔÖe××µµ

´×eØ! ÔÖe×× ´eµ

´ÐaÑbda For languages with classes such as Java, another

´beeÔµ ´ÓÐde eµµµµµµ strategy can be used. Call-backs may be imple- mented using class member functions. Member Since widgets call-backs are plain Scheme clo- functions may access the object and the object’s sures, they can be manipulated as first class ob- attributes for which they are invoked. Member jects, as in this example where new call-backs functions look like closures. However, member capture the values of the old call-backs in order functions are not closures because they are asso- to reuse them. ciated with classes. In other words, all the in- stances of a class share the implementation of all their member functions. That is, different call- 3.6 Reflection on event handling back implementations require different class dec- larations. For instance, if one wants to imple- ment a button with a call-back printing a plain Most modern widget toolkits (with the excep- message and another one emitting a sound, two tion of Qt [5]) use a call-back framework. That classes have to be defined. These class declara- is, user commands are associated with specific tions turn out to be an hindrance to simplicity and events (such as mouse click, mouse motion, key- readability. In addition, if several events must be board inputs, ...). Whenaneventisraised,the handled by one widget, this technique turns out user command is invoked. We think that the clo- to be impractical because it is not possible to de- sure mechanism is the most simple and efficient fine a new class for each kind of events the widget way to implement call-backs even if some alter- must react to (mouse-1, mouse-2, mouse-3, shift- natives exist. mouse-1,ctrl-mouse-1,shift-ctrl-mouse-1,...).

The rest of this section discusses how call- To avoid these extra class definitions, Java backs can be implemented depending on the fea- has introduced inner classes. An inner class is tures provided by the host language used to im- a class defined inside another class; it may be plement a graphical toolkit. anonymous. Because in GUI programming inner classes are used to implement call-backs and as they are numerous, Java proposes a new syntax 3.6.1 Languages that support functions with- that enables within a single expression, to declare

out environment and to instantiate an inner classe. For instance:

bÙØØÓÒºaddAcØiÓÒÄi×ØeÒeÖ´ ÒeÛ AcØiÓÒÄi×ØeÒeÖ´µ ß

ÔÙbÐic ÚÓid acØiÓÒÈeÖfÓÖÑed´AcØiÓÒEÚ eÒØ eµ ß ISO-C [16] supports global functions but no lo- a user code that may reference cal functions. A C function is always top-level current lexical bindings and may only access its parameters and the set of } global variables. C functions have no definition }µ

environment. However, without an environment,

AcØiÓÒÄi×ØeÒeÖººº a call-back is extremely restricted. In particular, a The expression ÒeÛ call-back is likely to access the widget that owns deserves some explanation: 1) it declares an it. In GTK · (a C toolkit) when a call-back is as- anonymous inner class that 2) implements the in- terface AcØiÓÒÄi×ØeÒeÖ and 3) it creates one

unique instance of that new class that is sent to

Ö BÙØØÓÒ the method addAcØiÓÒÄi×ØeÒe of the instance. That is, anonymous inner classes are the exact Java implementation of closures. It is worth pointing out that Scheme syntax for clo- sures is far more compact than the Java one.

3.6.3 Closures

Closures are central to GUI programming be- cause they are one of the most natural way to Figure 7: Two Biglook trees implement call-backs. As we have seen, all call- back based toolkits offer a mechanism similar to closures. It can be member functions or anony- mous Java classes or extra parameter passed to

C functions. However, we have found that solu- ure 6, lines 2 and 8.Thefirsttree(ØÖee½)isa

tions of non-functional programming languages class tree, its root is the Scheme ÓbjecØ class are not as convenient as Scheme’s ÐaÑbda ex- denoting the root of the inheritance tree (line 4).

pression because either the user is responsible The second tree (ØÖee¾) is a file tree. Its root

of the construction of the object representing the is "»", the root of the file system (line 10). To closure or extra syntax is introduced. compute the name of a node representing a class it is only required to extract the name of that class (line 5). The name of a node represent-

ing a directory is the node itself since the node ØÖee½ 1: ´defiÒe is a string (line 11). The children list of a class

2: ´iÒ×ØaÒØiaØe::ØÖee aÔaÒeµ

3: ´ÔaÖeÒØ is computed using the Bigloo library function Óbjecص 4: ´ÖÓÓØ

cÐa××¹×ÙbcÐa××e× (line 6). The children list cÐa××¹ÒaÑeµ

5: ´ÒÓde¹ÐabeÐ of a directory is computed by the library function cÐa××¹×ÙbcÐa××e×µµµ

6: ´ÒÓde¹chiÐdÖeÒ

diÖecØÓÖݹ>Ði×Ø ØÖee¾ 7: ´defiÒe (line 12). As one may no-

8: ´iÒ×ØaÒØiaØe::ØÖee tice “hooking” a tree to a data structure is a sim- aÔaÒeµ

9: ´ÔaÖeÒØ ple task. The resulting program is compact. We "»"µ

10: ´ÖÓÓØ think that this compactness is another strength of

´ÐaÑbda ´Üµ ܵµ

11: ´ÒÓde¹ÐabeÐ diÖecØÓÖݹ>Ði×صµµ 12: ´ÒÓde¹chiÐdÖeÒ Scheme closures.

Figure 6: Two Biglook trees In general, the Biglook API enables small source codes for GUIs. On a typical graphical interface we have found that the Biglook source is about twice smaller than the same interface im- Not only call-backs are easily implemented by plemented in Tcl/Tk and about four times smaller the means of closures but we have also found that than the interface implemented in C with GTK · . closures are handy to implement pre-existing data structure visualization. Consider the screen shot, Figure 7. It is made of two Biglook trees. A Biglook tree is a visualization of an existing data structure. That is, a Biglook tree does not contain data by itself. It only visualizes an existing struc- 4 Implementing Biglook ture. A Biglook tree is defined by three slots: i)

the root of the tree (ÖÓÓØ), ii) a function that ex- tracts a string which stands for the label of a node

( ÒÓde¹ÐabeÐ), iii) a function that computes the In this section, we present the overall Biglook

children list of a node (ÒÓde¹chiÐdÖeÒ). The architecture and implementation. Then, we detail declaration of the trees of Figure 7 are given Fig- theroleofvirtual slots. . irr Architecture Library 4.1 native fters ftelbayo hsmnmlbasis. minimal this on library the of rest building the the of allows slots Sec- virtual using in that as see 4.2 tion used will We be back-end. can Biglook such, potential as and, prerequisites these toolkit. architecture Biglook underlying the the of shows wid- 8 primitive widgets, Figure using some gets. lacks them back-end implements a Biglook if addition, In datg fteef takes the It of available). advantage are back-end Swing a and end re aif hsciei T,GTK (Tk, criteria have this we satisfy toolkits the tried All events. any hide string, not on. does a so integer, and an function, as representa- a such the differ, can if used even tion this, all provide course toolkits Of the interface. the of component ticular a back-end, provide: Biglook must potential generally toolkit a be is To back-end possible. another im- to its plementation re-targeting toolkit, underlying the about technical [12]. previous report a in Interested implementations these of 1. Figure presented can readers one the as interfaces such graphical complex using implement applications to used As be can marginal. Biglook consequence, is a time execution in allocations). memory difference additional low The of a 15% imposes (about overhead it and operations level iue8 h ilo otaearchitecture software Biglook The 8: Figure h ilo irr sipeetdo o fa of top on implemented is library Biglook The culgahcltokt eeal support generally toolkits graphical Actual eas ilo ae e assumptions few makes Biglook Because back-end

User Application fi dpeiepromneevaluation performance precise nd oli cretyaGTK a (currently toolkit ÔaÖeÒص fi Ó::Ðabeе inyo the of ciency i) ii) a oietf par- a identify to way a neetmngrthat manager event an ´bÙiÐØiÒ Biglook Ó ´bÙiÐØiÒµ Ó Öead¹ÓÒÐݵ · back-end n Swing). and

´ÖeaÐiÞe¹ÛidgeØ Back−end

< ´Ó::Ðabeе (GTk+/Swing/...) bÙiÐØiÒ ´ · back- low ÛidgeØ::ÓbjecØ ÐabeÐ::ÛidgeØ ´×eØ! ´ÐaÑbda < ´geØ ´ ´ÛiØh¹acce××::ÐabeÐ ´bÙiÐØiÒ¹ÛidgeØ ºººµ ´ØeÜØ ´ÛiØh¹acce××::ÐabeÐ ÐabeÐ Biglook and Slots Virtual 4.2 ÖeaÐiÞe¹ÛidgeØ the Implementing fi back-end. the of pendent ueta hscasetnsthe extends class this that sume ok hyihrtfo the from frame- inherit same they the work: to according widgets implemented simple All are widget. builtin a into mapped level rsn eeapsil mlmnaino the of implementation possible a We here slots. present virtual using implemented are options de they etto.Vrulsosaeue opoiean provide to A used class-based oriented are object imple- slots native Virtual their and mentation. widgets of view of user point used Biglook between are connection interact slots the Virtual establish directly to toolkit. functions back-end the setter with and getter Its ene owieis: method write the to label, need object a we For graphical class. the the create with associated to back-end must the and call function generic this overrides method speci ihol n diinlso:the slot: additional one only with sgvnt h ytmvategnrcfunction generic the via system the to given speci is initialization class The initialized. ´cÐa×× ´defiÒe¹ÑeØhÓd ´cÐa×× e,w utde must we ned, o httesoso ae igtaede- are widget label a of slots the that Now ipewde sawde hti directly is that widget a is widget simple A hsmto rae uli ae i h low the via label builtin a creates method This fi < stelbltext. label the es builtin-label-text-set! builtin-label-text ls.Frtesk fsmlct,w as- we simplicity, of sake the For class. fi builtin-make-label eue utmzto pin.These options. customization user ne builtin-make-label Ú::ÔÖÓcedÙÖeµ ´bÙiÐØiÒµ fi bÙiÐØiÒµµµµ ØeÜØ Ó o ahcaso h irr a library the of class each For . ehwsc igthst be to has widget a such how ne > bÙiÐØiÒ ltrqie ita slots. virtual requires slot > > ´Ó::ÐabeÐ ÔaÖeÒصµµµ ucinadstores and function PI > ÛidgeØ oBgok inde- Biglook, to ØeÜØ ÛidgeØ ´ÐaÑbda < ´×eØ ´ ls and class ´ÛiØh¹acce××::ÐabeÐ ltthat slot fi code c class Úµµµµµµ the result in the bÙiÐØiÒ slot. This slot creates tribution for strict functional programming lan- the link between the Biglook toolkit and the back- guages has been developed for the Caml pro- end. gramming language [30].

The first attempt, CamlTk, is quickly surveyed in [23]. The design of CamlTk is different from 5 Related work the one of Biglook. CamlTk binds Tk functions in Caml while Biglook provides an original API made of classes. Many functional languages are connected to widget libraries especially to the Tk toolkit. Few Recently a new widget library based on GTK· of them use object-oriented programming except has been proposed for Caml. No article describes in the Scheme world, we can cite mainly STk, that connection. However, some work has been SWL and MrEd. described to add keyword parameters to Caml in order to help the connection with widget li- braries [10]. The philosophy of that work dif- 5.1 Scheme widget libraries fers from ours because that new library makes the

GTK· API available from Caml. No attempts are made to present a neutral API as we did for STk [11] is a Scheme interpreter extended with Biglook. the Tk graphical toolkit. To some extent, STk is the ancestor of Biglook, since it was developed Programming graphical user interfaces with by one of the authors of this paper. However, lazy languages is far more challenging than with STk is tightly coupled to the Tk toolkit and even strict functional languages. The problem is to if this toolkit is presented to the user through an tame the imperative aspects of graphical I/O object oriented API as in Biglook, no provision in such languages [18, 28]. Several solutions was made to be independent from this back-end. have been proposed: Fudget by Carlsson and Hallgren [2, 3], Haggis by Finne and Peyton SWL is a contribution to the Petite Chez Jones [8], TkGofer by Vullings and Claessen [4] Scheme system [6]. It relies on an interpreter and and, more recently the extension of the former uses Tk as back-end. In SWL, native Tk wid- TclHaskell library: FranTk by Sage [24]. gets are mapped to Chez Scheme classes and in this respect this toolkit is similar to the Biglook or STk libraries. However, SWL implementation is very different from the one used by those li- braries since SWL widgets explicitly talk with a regular Tcl/Tk evaluator. Conclusion

MrEd [9], a part of the DrScheme project [7], is a programming environment that contains an interpreter, a compiler and other various pro- gramming tools such as browser, debugger, etc. In this paper we have presented Biglook, a The back-end toolkit used by MrEd is wxWin- widget library for the Bigloo system. The archi- dow [27], a toolkit that is available under various tecture of Biglook enables different ports. Cur- platforms (Unix, Windows, etc.). As STk, this rently two ports are available: a GTK· port and toolkit is completely dependent of its back-end. a Swing port. Biglook source code can be indif- ferently linked against the two libraries. Biglook API uses an object oriented programming style 5.2 Other functional languages widget li- to handle graphical objects and a functional ori- braries ented programming style to implement the inter- face reactivity. We have found that combining the two programming styles enables more com- Other functional languages provide graphical pact implementations for GUIs than most of the primitives using regular functions. The main con- other graphical toolkits. Acknowledgments [14] J. Gosling, B. Joy, and G. Steele. The JavaTM Language Specification. Addison-Wesley, 1996. [15] J. Gosling, F. Yellin, and the Java Team. The TM Many thanks to Keith Packard, Jacques Gar- Java Application Programming Interface, Vol- ume 2: Window Toolkit and Applets. Addison- rigue, Didier Remy, Peter Sander, Matthias Wesley, 1996. Felleisen, Simon Peyton Jones and to Celine´ for [16] ISO/IEC. 9899 Programming Language - C. Techni- their helpful feedbacks on this work. cal Report DIS 9899, ISO, July 1990. [17] R. Kelsey, W. Clinger, and J. Rees. The Revised(5) Re- port on the Algorithmic Language Scheme. Higher- Order and Symbolic Computation, 11(1), September References 1998. [18] R. Noble and C. Runciman. Functional Languages and Graphical User Interfaces Ð a review and a case [1] D. Bobrow, L. DeMichiel, R. Gabriel, S. Keene, study. Technical Report 94-223, Department of com- G. Kiczales, and D. Moon. Common lisp object sys- puter Science, University of York, February 1994. tem specification.Inspecial issue, number 23 in SIG- PLAN Notices, September 1988. [19] J. Ousterhout. Tcl and the Tk toolkit. Addison-Wesley, 1994. [2] M. Carlsson and T. Hallgren. FUDGETS - A Graph- ical User Interface in a Lazy Functional Language. [20] H. Pennington. Gtk+/Gnome Application Develop- In FPCA ’93 - Conference on Functional Programming ment. New Riders Publishing, 1999. Languages and Computer Architecture, pages 321–330. [21] C. Queinnec. Designing MEROON V3.InWorkshop on ACM Press, June 1993. Object-Oriented Programming in Lisp, 1993. [3] M. Carlsson and T. Hallgren. Fudgets — Purely Func- [22] D. Remy´ and J. Vouillon. Obective ML: A simple tional Processes with applications to Graphical User object-oriented extension of ML.InSymposium on Interfaces. PhD thesis, Department of Computing Sci- Principles of Programming Languages, pages 40–53, ence, Chalmers University of Technology, S-412 96 1997. Gteborg, Sweden, March 1998. [23] F. Rouaix. A Web navigator with applets in Caml. [4] K. Claessen, T. Vullinghs, and E. Meijer. Structuring In Proceedings of the 5th International World Wide Graphical Paradigm in TkGofer.InInt’l Conf. on Web Conference, in Computer Networks and Telecom- Functional Programming, 1997. munications Networking, volume 28:7–11, pages 1365– [5] M. Dalheimer. Programming with Qt.O’Reilly, 1st 1371. Elsevier, May 1996. edition, april 1999. [24] M. Sage. FranTk Ð A declarative GUI language for [6] K. Dybvig. Chez Scheme User’s Guide. Cadence Re- Haskell.InInt’l Conf. on Functional Programming, search Systems, 1998. Montral, Qubec, Canada, September 2000. [7] M. Felleisen, R. Findler, M. Flatt, and S. Krishnamurthi. [25] M. Serrano. Bigloo user’s manual. RT 0169, INRIA- The DrScheme Project: An Overview.SIGPLAN No- Rocquencourt, France, December 1994. tices, 1998. [26] M. Serrano. Wide classes.InProceedings ECOOP’99, [8] S. Finne and S. Peyton Jones. Composing Hag- pages 391–415, Lisbon, Portugal, June 1999. gis.InFifth Eurographics Workshop on Program- [27] J. Smart. wxWindows toolkit Reference Manual.

ming Paradigm for Computer Graphics, Maastricht, available at hØØÔ:»»ÛebºÙkÓÒÐiÒeºcÓºÙk »jÙ ÐiaÒ ¹ NL, September 1995. º×ÑaÖØ»ÛÜÛiÒ, 1992. [9] M. Flatt, R. Findler, S. Krishnamuryhi, and [28] T. Vullings, D. Tuijnman, and V. Schulte. Lightweight M. Felleisen. Programming Languages as Op- GUIs for Functional Programming.InInt. Symp. erating Systems (or Revenge of the Son of the Lisp on Programming Languages, Implementations, Logics, Machine).InInt’l Conf. on Functional Programming, and Programs, 1995. Paris, France, 1999. [29] K. Walrath and M. Campione. The JFC Swing Tu- [10] J. Furuse and J. Garrigue. A label-selective lambda- torial: A Guide to Constructing GUIS. Addison- calculus with optional arguments and its compilation Wesley, July 1999. method. Technical Report RIMS Preprint 1041, Re- search Institute for Mathematical Sciences, Kyoto Uni- [30] P. Weis and al. The CAML Reference manual. Tech- versity, October 1995. nical Report 121, INRIA-Rocquencourt, 1991. [11] E. Gallesio. STk Reference Manual. Technical Report RT 95-31a, I3S-CNRS/Univ. of Nice–Sophia Antipolis, July 1995. [12] E. Gallesio and M. Serrano. Graphical user interfaces with Biglook. Technical Report I3S/RR–2001-13–FR, I3S-CNRS/Univ. of Nice–Sophia Antipolis, September 2001. [13] A. Goldberg and D. Robson. Smalltalk-80: The Language and Its Implementation. Addison-Wesley, 1983.