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

¢¡¤£¦¥¨§ © ¢ ¦¦£¦£¦¥©¡ ¤ ¦¢© ¦¡¡ ¦£!¢¡£¦ ©¡

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: #%$&$&')(+*,*-/.,0%1324)5 6,472&8¤9:5<;=3*>72?/10&0- . shots of Biglook applications: i) -&B,=/0¤CD¤9 on the left and ii) the Biglook dock applications, a` la NextStep, on the right. These Biglook applications 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 beneﬁts from the high how to apply the functional style to GUIs pro- 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 1&0&.&A ical applications (e.g., @ , editors a` la delivers small and efﬁcient applications for the Emacs, browser a` la Netscape, programming UnixTM operating system. Bigloo is able to pro- tools such as -&B%=%0¤CD¤9 , 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 allocate 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, we always had to decide which model to choose: the functional 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 ¢¡¤£¦¥¨§ ©¨ module-name ¡ £¦

Section 2. In Section 3 we present the Biglook import ¦ ¨¨ £¦

library. We start showing a simple Biglook ap- export ¦

¨ ¦

static plication and its associated source code. Then, © !¨"

static #¦

we detail the Biglook programming principles (widgets creation, event handling, etc.) motivat- opt-body ing our design orientations by programming language 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 identiﬁer 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 identiﬁers but prototypes. It is then possible to export variables (mu-

¢¡¤£¦¥¨§ ©¨ ¡¤£¦¥¨§ ©¨ £

¨©¨ £

table bindings) or functions (read-only bindings). ¨¨ £¦

£ ¤

Static clauses are optional (the bindings of a mod-

¥ £§! ©¨ ¥ ¦§ ©¦ ¡¢¡

ule which are not referenced in a clause are, by

" ¥ £§! ©¨ ¥ ¦§ ©¦ ¡¢¡

default, static).

¨©¨ £ ¨¥ £

¡¢¡

! ¥ £§! ©¨ ¥ ¦§ ©¦ ¡¢¡

Library clauses enable programs to use Bigloo

£ ¤

libraries. A Bigloo library is merely a collec- ¥

©¨ ¨ ¨£§¢

tion of pre-compiled modules. Using a library is

©¨ ¡ !¥ £!" £

¡¢¡

¤# ¨£§¢ !$&% ¨£§¢

equivalent to importing all the modules compos- ¦ ¨

(') £* £ ' ¨£§¢

ing the library. Detailed information on Bigloo ¡ modules may be found in the two papers [25, 26].

1.2.2 Instances 1.2 Object layer

When declaring a class +-,. , Bigloo automat- /

ically generates the predicate 81&. , an allo-

2¦4D¢$/.4%$2.$%9 (,(

cator +-,. , an instance cloner

1/2&8¤.$/9:(,( 81&.1

In this paper we assume a CLOS-like object A6,' @

+-,0. , accessors (e.g., for

%D¤9$32

model with single inheritance and single dis- 8¤1&. @ a slot @ ), modiﬁers (e.g., for a patch. The object layer implemented in Bigloo

slot @ ) and an abbreviated special access form,

¤&.38,8¤9/D,D (,( is a restricted version of CLOS [1] inspired, to a C2$&#

+4,0. , 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

©¨ ¨ * ¨ £ ¨¥

¡¢¡

" <;

=%9

1.2.1 Class declarations ;; The initialization value of a slot can be omitted

;; from the arguments list if it has a default value;

;; this is the case for the slot of class > ?@BADCFEHG¨I .

KJ¤ L0¨ ¦ £ ¨¥ "M

Classes can be declared static or exported. It

¡¢¡

FN !$ FN FN " FNO

is then possible to make a declaration accessible

from another module or to limit its scope to one

C2¦$&#P&.38&8¤93D,D module. The abbreviated syntax of a class decla- 2¦4D¢$%.¤4%$2.¤$/9 ration is: The and special

forms are implemented by the means of macros

¨©¨

¡¢¡ that statically resolve the keyword parameters

class-id super-class-id opt-init opt-slots

Q R (such as @ , and ). For instance, the above ex-

ample is expanded into:

¢¡*S £ ¨¥T%9O <;O

A class can inherit from a single super class. ©¨ ¨

FN !$ FN £ ¨¥¦

Classes with no speciﬁed super class inherit from

0¤B¤£,9/8¢$

FN £ ¨¥¦"

the class. The type associated with a sub-

FN £ ¨¥* 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 ¦¥¨§¨© (,( ) and may have a default value

( A%9&;%.¤631¤$ option). Here are some possible decla- Generic function declarations are function decla-

2¦4%$ '30 24%$¤&A ?/9¤439=72&8 rations for the traditional '/0 and : rations annotated by the keyword. They

¥ ¡ ¨L £¦¥ BL £FJ £ £

¡¢¡

KJ¤ L0¨ ¦ £ £ "

can be exported, which means that they can be

¡¢¡

'©¨D'

used from other modules and that methods can

'"©¨D' "

be added to those functions from other mod-

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

¥ ¡ ¨L £¦¥ BL £FJ £ £ ¨¥

¡¢¡

KJ¤ L0¨ ¦ £ ¨¥ £ !

sible from within other modules, hich means that ¡¢¡

¢F ¨¡ ¨L £¦¥

no other modules can add methods. The CLOS ¦©©

' ©¨D'

model ﬁts harmoniously with the traditional functional programming style because a function can be thought as a generic function overridden with Hereafter is an example of a call to the D#30¤C exactly one method. The syntax to deﬁne a generic function.

generic function is similar to an ordinary function

©¨ ¨ * ¨ £ ¨¥

deﬁnition: ¡¢¡

=%B

¥ ¡ * ¨ ¦ ¢¢

¡¢¡ ¡¢¡

" ¢

fun type arg class opt-

! M; ©

body

BL £FJ x=10 y=20 z=465

Generic functions must have at least one argument 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 ﬁrst 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

¥ ¡ ¨L £¦¥ ¢¢

¡¢¡ ¡¢¡ fun type arg class body Section 1.2.1, and virtual slots that enable several 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

8.%1,114/9 $¤¥¤79$¤A§¦

@ form. It calls the method Section 1.2.2, the compiler automatically deﬁnes that should have been used if the current method getters and setters that access the various values had not been deﬁned. 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

24%$ '30 2¦4,$¤&A

the slots of the '30 and instances. This generic function is named D#30¤C : their getters and setters are not generated by

the compiler. They are deﬁned by the user,

¥ ¡ * ¨ ¦ BL £FJ £ £

¡¢¡ in the class deﬁnition, using the class slot

D¤9$ options: ?%9$ and .

they are not allocated into memory.

Then, the generic function is overridden with a

2¦4%$ '30 2¦4,$¤&A method for classes '/0 and . For instance, let us consider a possible rectan-

gle class implementation. An instance of =/9/8¢$

Q is characterized by its origin ( @ , ) and either

¡ Q¡

its upper right point ( @ , ) or its dimension

#/9 2?&#%$

( C2¢A&$&# , ). In the following class deﬁni-

#/9 2?&#%$

tion, the C2¢A$&# and slots are virtual.

¨©¨

" ¦% "¦%

KJ¤ ¥L ¨ ©¨ ¡ !¥ £

KJ¤ L0¨ ¦ £ ¦%

¡¢¡

¦%

Figure 2: A simple example

¦ ¨ ©¨ ¡ !¥ ££¢

KJ¤ L0¨ ¦ £ ¦%

¡¢¡

¦ ¨¤# ¦% !$ £¢

KL L ¨ ©¨ ¡ !¥ £

KJ¤ L0¨ ¦ £ " "¦%

Our reﬂection on how to create a widget or how

¡¢¡

"¦% "

to handle interfaces events are presented in Sec-

¦ ¨ ©¨ ¡ !¥ ££¢

tions 3.3 and 3.6.

KJ¤ L0¨ ¦ £ " "¦%

¡¢¡

¦ ¨¤# "¦% !$ "¤¢

3.1 A Biglook example

#39 2?&#,$

Setting the C2¢A&$&# virtual slot (resp. the ¡

slot) automatically adjusts the @ value (resp. the ¡

Q value) and vice versa. No memory is allocated Biglook uses a declarative model for constructing

#/9 2?&#%$ for C2¢A$&# and , as their values 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 application. 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 ﬁed independently of its creation by associating an action (a Scheme closure) with a widget spe- ciﬁc event (key pressed, mouse click, mouse mo- Biglook is an Object Oriented Scheme library tion, . . . ).

for constructing GUIs. It offers an extensive

¢¡¤£¦¥¨§ ©¨ ¨ ¡ ©¨ © !¨" !¤ ©££FS set of widgets such as labels, buttons, text edi- 1:

*J¤

tors, gauges, canvases. Most of the functional- 3: ¥

* ¨ J¤ ¥ £FJ

ity it offers are available through classes rather 4: ¡¢¡

©¨ '§¦©¨ ©££FS ¨ ¡ ©¨ ¦'

than through ad-hoc functions. For instance, in- 5:

¥ BL BS

2&8¤0¤42¢; 6:

* ¨ BL BS0!§ £*

stead of having the classical functions ,

¡¢¡

C2¦4/A%0¤C¤32&8¤0¤42¢;729&A1/

A%932&8¤0¤42; 7:

¨ * *J¤ Q and for the

C24/A%0¤C

¨(' §¢¥ ¨ © ¦'

widget, Biglook offers the virtual 9:

¥ ¨¨¥ £

2&D%2¦B 19

slot ¥ to implement this functional- 10:

* ¨ ¨¥ £ ¡¢¡

2&D%2¦B31&9 11:

¨ * *J¤

ity. Setting the slot enables iconiﬁca-

1&9

2&D%2B 12:

£¦ *¨ £F

13:

! £¦¥ ¨FJ¤ ¥L

unveils the window iconiﬁcation state. As we 14:

¨ F' ! £©¦¥D''¨ © ¦ 0'M' ©¨ '

will see, this design choice yields a simpler API 15:

¦!§ £F

16: ¥

* ¨ !§ £F

and allows usage of introspective techniques for ¡¢¡

17:

¨ * *J¤ GUIs programming.

18:

19:

¨ '§¤ D'

In Section 3.1 we ﬁrst present a small interface 20: and discuss how to create the widgets which compose 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 creates a window (line 4), and three widgets (line 7, 3.3 Reﬂection 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, border sizes, . . . ), some others describe the internal state of the button (widget parent, as- The graphical objects (i.e., widgets) defined sociated value, associated text, . . . ). In general, 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 24D¢$/.¤4,$2.$/9:(,( Biglook by the 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

¢£¦ *¨ £F0¦ ¨¤# ¨¨¥ £ ¢ ¨ ¦ ¦© ¨¥ £ each declared slot is provided with a value, there

is no run-time overhead associated with forms (,( such as 2¦4D¢$/.4%$2.$%9 . 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, speciﬁc attributes have to be pro-

¨¥ £¢£¦ *¨ £F ¨¨¥ £ vided. Even overloading and class constructors 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 deﬁnition 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

P&.38&8¤93D,D C2¦$&# this is impractical because, in general, overload- :

ing dispatches on types only and several slots can

KJ¤ L0¨ ¦ ¨¥ £ ¨¨¥ £ £¦ *¨ £F ¡¢¡

have the same type. For instance, imagine that we

¦ ¨¤# £¦ *¨ £F ¢ ¨ ¦ ¦©

want to change the graphical appearance of our

£¦ *¨ £F 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 speciﬁc value.

We can turn the deﬁnition of Figure 3, line 4 to:

*J¤

¥ Figure 4: An horizontal layout

* ¨ J¤ ¥ £FJ

¡¢¡

©¨ ='§¦©¨ ©££FS ¨ ¡ ©¨ ¦'

KJ¤ ¥L ¢¢

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

can use: in the window, an horizontal @ :

¥ *J¤

*J¤

¥ 1:

* ¨ J¤ ¥ £FJ

* ¨ J¤ ¥ £FJ ¡¢¡

¡¢¡ 2:

©¨ ='§¦©¨ ©££FS ¨ ¡ ©¨ ¦'

KJ¤ ¥L ¢¢

¥ ¦! £¦

KL L ¢¢

* ¨ ! £¦

6: ¡¢¡

¨ * *J¤

£¦ *¨ £F

Languages relying on type overloading cannot 8:

BL BS propose these different constructors because the ¥

10:

* ¨ BL BS0!§ £F

width and the height of a window are of the same 11: ¡¢¡

¨ * ¦! £¦

type. 12:

¨ ' §¢¥ ¨ © ¦'

13: ¢¢ 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 2¦4/9= 8¤04%$/. 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 deﬁned line 4 of Fig- ure 3, is a container, it “contains” the three other

widgets. With the exception of windows, all wid-

*J¤

1: ¥

* ¨ J¤ ¥ £FJ gets must be associated with a container in order

2: ¡¢¡

©¨ ='§¦©¨ ©££FS ¨ ¡ ©¨ ¦'

to be visible on the screen. To associate a widget

'3.=/9¤4,$ 3:

with a container, one have to set its slot 4:

¨¦!

(see lines 8, 12 & 18 of Figure 3). Biglook pro- 5: ¥

* ¨ £¦ ¦ ¨¥

6: ¡¢¡

¨ * *J¤ poses several kind of containers: aligned contain-

ers (such as boxes and windows), grid containers, 8:

¦ *

note pad containers, paned containers, containers 9: ¥

* ¨ * ¨¥

with scrollbars, etc. 10: ¡¢¡

£¦ *¨ £F

11:

¨ * ¨¦!

12:

Let us present here two examples of contain- 13:

£©©

ers. First, let us consider that we want to modify 14: ¥

* ¨ £©©

the interface of Figure 2. We want the buttons 15: ¡¢¡

¨ * ¦ * to be displayed horizontally instead of vertically 16:

BL BS

17: ¥

* ¨ BL BS0!§ £F Graphical events (mouse click, key pressed,

18: ¡¢¡

¨ * £©© window destruction . . . ) can be associated with

19:

9 9¤4%$

¨(' §¢¥ ¨ © ¦' ¥ 20: widgets by the means of the widgets slot.

21: This slot must contain an instance of the class

¥ ¨¨¥ £

9¤4,$¤#3.¤4%A/1&9=

22: 9

* ¨ ¨¥ £

¡¢¡ which is deﬁned as:

23:

¨ * ¦ *

¨©¨ ¢ *FL *¥ ©¨ ¨

24:

! £¦¥ ¨FJ¤ ¥L

¨£F ¨§ £ ¦ ¨¥¨§ ¥ ¦§ ©¦ ¢¢

25: ¡¢¡

£¦ *¨ £F

26:

F' ! £©¦¥D'M'¨ © ¦ 0'' ©¨ '

¨ ;; window events

¥ £¦" £ ¦ ¨¥¨§ ¥ ¦§ ©¦ ¢¢

27: ¡¢¡

28: ¢¢

¦!§ £F

29: ¥

* ¨ !§ £F

¡¢¡ ;; mouse events

30: ¡¢¡

¨ * *J¤

31: ¡¢¡

¢¢

32:

¨('§¤ D'

33:

;; keyboard events

¡¢¡

¢¢ Note that even if the interfaces of Figures 2 and

5 seem quite different, we only need to modify .¤=/.&A720 the parent slot of the .38#3938- and wid-

gets to embed them in the new containers .$/.¤B Each slot of an event-handler is a procedure .3D,8¢=%0%1,1 (line 6), .¤'3.¤4/9 (line 10) and (line 15). called a call-back that accepts one argument. 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

9 9¤4%$

the ¥ class which is deﬁned as:

plex G s with minimal efforts. In general, when ;; the widget which receives the event

building such interfaces, one of the main difﬁcul-

ties lies in trying to separate the code of the in- ;; the button number or -1

;; the modiﬁers list (e.g. shift)

GUI code independent from the rest of the appli- ¡¢¡

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

¨¥£F ©¦"

¡¢¡

;; the y position of the mouse

" ¨¥£F ©¦"

¡¢¡ GUIs are often built on a trial-fail basis. It

;; the character pressed or -1

is hard to conceive an interface ex-nihilo, ¡¢¡

and it is generally after using it for a while ¢¢ that the elements of the GUI ﬁnd 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-

H ¨ ¢ *!§ £F %

A given program can have several interfaces ¨

according to the device on which it is run 4: ¡¢¡

KJ¤ L0¨ ¦ !§ £F ¦!§ £F ¢ *

(e.g. graphical screen, PDA, alphanumeric ¡¢¡

¤# ¢ * ¢ terminal). With an independent interface ¦ ¨

code, different interfaces can be connected $ to the same program. 9

That is, on line 4 we allocate ¥ , an instance of

9 9¤4%$.4/A/1&9=

The GUI of an application can be con- the ¥ 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 '%=/93D,D 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 9 being bound to an instance sociated with an event, an optional value may be

9 94%$

of the ¥ class. This function checks the but- speciﬁed 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 ﬁrst 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:

KJ¤ L0¨ ¦ !§ £F ¦!§ £F ¢ *

¡¢¡

£©¦¥

¦ ¨¤#

©¨ ¡ !¥

! ¦ £©¦¥

For languages with classes such as Java, another

strategy can be used. Call-backs may be implemented 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 instances 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 declarations. For instance, if one wants to implement 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, . . . ). When an event is raised, 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 deﬁnitions, 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 deﬁned 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:

!§ £F¤ ¨¥¥ ¦ £F¡ ¦ * ¨ ! *J ¦ £F¡ ¦ * ¨

£¢

¦¢ 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 deﬁnition

environment. However, without an environment,

©¨ 8¢$20¤4 72&D¢$/9439= 5,55 a call-back is extremely restricted. In particular, a The expression 439C 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-

78¢$2¢0¤4 72&D$/9¤439= terface ¨ and 3) it creates one

unique instance of that new class that is sent to

¨78¢$720¤4 72D¢$/9¤439= >,6%$,$%0¤4 the method .A,A of the instance. That is, anonymous inner classes are the exact Java implementation of closures. It is worth pointing out that Scheme syntax for closures is far more compact than the Java one.

3.6.3 Closures

Closures are central to GUI programming because 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 $,=/9,9

C functions. However, we have found that solu- ure 6, lines 2 and 8. The ﬁrst tree ( ) is a

¤£&938¢$

tions of non-functional programming languages class tree, its root is the Scheme 0¤B class

¤3B/A%.

are not as convenient as Scheme’s 1. ex- denoting the root of the inheritance tree (line 4). ¦¥

pression because either the user is responsible The second tree ( $&=/9,9 ) is a ﬁle tree. Its root

* § of the construction of the object representing the is § , the root of the ﬁle 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

* ¨

2: ¡¢¡ is a string (line 11). The children list of a class

¨ * ¦ *

3: is computed using the Bigloo library function

££¦ £!"

81&.3D&D /D6,B781&.3D,D93D

of a directory is computed by the library function

¦¨,132&D$

6: A72=/9/8¢$/0=

¥ ©

7: Q (line 12). As one may no-

* ¨

8: ¡¢¡ tice “hooking” a tree to a data structure is a sim-

¨ * ¦ *

££¦ '¢¡¨' ple task. The resulting program is compact. We

10:

think that this compactness is another strength of

11:

12: 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 deﬁned by three slots: i) the root of the tree ( =%0,0$ ), ii) a function that ex-

tracts a string which stands for the label of a node

&1&.¤B39%1

( 430&A%9 ), iii) a function that computes the In this section, we present the overall Biglook

/8#21A&=/9¤4 children list of a node ( 430&A,9 ). The architecture and implementation. Then, we detail declaration of the trees of Figure 7 are given Fig- the role of virtual slots. le o In a adv readers of Biglook tion gets. plementation of The end such these possible. applications potential 4.1 of ticular about toolkit nati the report tried a does tion v consequence, v function, erhead Figure Actual The Because the the these el addition, antage v toolkits and 4.2 dif used e not satisfy as Figure operations prerequisites Library the Biglook rest [12 bac Biglook component ference must that can a the implementations hide implements Biglook 8: User Application ]. (about can Swing T underlying k-end of graphical of o and using pro The ﬁnd this one Biglook 8 pro using if the be an the dif to sho toolkit. in Biglook library vide a y Ar so vide: toolkit criteria a Biglook library fer back-end precise presented 15% and another ef e back-end e virtual back-end. ws potential v of x on. chitectur comple and, ﬁcienc , ents. ecution this, such toolkits the them the toolkit, it i) is mak of ii) (currently can on imposes (Tk, as a implemented slots performance All interf softw underlying additional e in back-end y as an w x are es v this such, Biglook Figure using be lacks time en Biglook of ay a graphical W the an GTK e e re-tar allo a generally pre v used ace. fe are the e if v minimal to ent inte ailable). toolkits w will is a vious can ws the a some primiti identify architecture " bac geting 1. mar manager to Of lo GTK ger assumptions allocations). is and the architecture back-end, w representa- see be implement

on Back−end e k-end Interested course interf , ginal. generally v technical widgets, basis. memory b a (GTk+/Swing/...) we aluation v Swing). " used support top It in uilding e its string, a back- tak ha wid- Sec- aces par that of lo im- As all v as es w a a e - w are options mapped is present the 4.2 ﬁned, initialized. pendent speciﬁes Implementing with Its le sume mentation. object associated to we method with call point =/9,.%1/2 1&.¤B39,1 ¨©¨ ¨©¨ ¥ ¢ KJ¤ KJ¤ v ork: A No This establish gi el y need getter ¨

KJ¤ ¢¢ implemented v the !§¤ ©¦ 0FJ¤ L0¨ L0¨ ¡ ¦ ¨ ¡ only the deﬁne simple w ¨ en of ©¨ ©¨ £ we V that R oriented L0¨ ¡ ¨L £¦¥ ¦ ¨¤# b b class. the method b J¤ ©¨¦! 9C2¢A&?/9$ irtual are o that uiltin-label-te uiltin-label-te here into of back-end ¡ !¥ ¡ !¥ vie to ¦ ¦ uiltin-mak back-end to the v must ¥© ¨ one y and errides with © ¦ the this write w the implemented The the V user inherit label a the widget !§¤ ©¦ ¡ ¡¢¡ irtual a of F £ £ ¡¢¡ ¡¢¡ ¡¢¡ the b additional back-end. deﬁne ¥© ¨ J¤ Slots setter class-based connection creates or b the uiltin class system possible ©¨¦! ©¨¦! £!" ¡¢¡ © H FJ¤ ¡¢¡ ¡¢¡ class uiltin-mak slots is: widgets ¥© ¨ customization according $/9 this te ©¨¦! ©¨¦! ©¨¦! . to the toolkit. xt-set xt e-label © © class. F xt. slots from ¨¥£F ©¦" ¢ @ is or and ho © © © create widget. functions e $ initialization generic sak of £ £ xtends a ! !§¤ ©¦ a each slot w via ¢ ¢ e-label £

or V A of ¥© ¨ label !§¤ ©¦ requires the the class to irtual function P used a All £ ¦ ¨¥¨§ their C2¢A&?/9$ ¢ function I the simplicity the a label, virtual to the generic label graphical directly options. widget £ that widget simple of ¨ * Biglook, ¡¢¡ $/9 C2¢A?/9$ slots to nati speciﬁc Biglook same ©¨¦! virtual the @ ¨ * the via pro and is $ slots. v class © and has are e function library , slot widgets directly vide method interact the are we frame- imple- of object These stores slots. inde- must class to code used user that lo and W de- the as- be an w e a the result in the B,621¤$2¦4 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 ﬁrst 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 libraries [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 libraries 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 programming 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 interface 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 [11] E. Gallesio. STk Reference Manual. Techni- cal Report RT 95-31a, I3S-CNRS/Univ. of Nice– Sophia Antipolis, July 1995. Many thanks to Keith Packard, Jacques Gar- [12] E. Gallesio and M. Serrano. Graphical user rigue, Didier Remy, Peter Sander, Matthias interfaces with Biglook. Technical Report Felleisen, Simon Peyton Jones and to Celine´ for I3S/RR–2001-13–FR, I3S-CNRS/Univ. of Nice– their helpful feedbacks on this work. Sophia Antipolis, September 2001. [13] A. Goldberg and D. Robson. Smalltalk-80: The Language and Its Implementation. Addison- Wesley, 1983. References [14] J. Gosling, B. Joy, and G. Steele. The JavaTM Language Speciﬁcation. Addison- Wesley, 1996. [1] D. Bobrow, L. DeMichiel, R. Gabriel, S. Keene, [15] J. Gosling, F. Yellin, and the Java Team. The G. Kiczales, and D. Moon. Common lisp ob- JavaTM Application Programming Interface, ject system speciﬁcation. In special issue, num- Volume 2: Window Toolkit and Applets. ber 23 in SIGPLAN Notices, September 1988. Addison-Wesley, 1996. [2] M. Carlsson and T. Hallgren. FUDGETS - A [16] ISO/IEC. 9899 Programming Language - C. Graphical User Interface in a Lazy Functional Technical Report DIS 9899, ISO, July 1990. Language. In FPCA '93 - Conference on Func- tional Programming Languages and Computer [17] R. Kelsey, W. Clinger, and J. Rees. The Re- Architecture, pages 321–330. ACM Press, June vised(5) Report on the Algorithmic Language 1993. Scheme. Higher-Order and Symbolic Computa- tion, 11(1), September 1998. [3] M. Carlsson and T. Hallgren. Fudgets — Purely Functional Processes with applications [18] R. Noble and C. Runciman. Functional Lan- to Graphical User Interfaces. PhD thesis, De- guages and Graphical User Interfaces – a re- partment of Computing Science, Chalmers Uni- view and a case study. Technical Report 94-223, versity of Technology, S-412 96 Gteborg, Swe- Department of computer Science, University of den, March 1998. York, February 1994. [19] J. Ousterhout. Tcl and the Tk toolkit. Addison- [4] K. Claessen, T. Vullinghs, and E. Meijer. Struc- Wesley, 1994. turing Graphical Paradigm in TkGofer. In Int'l Conf. on Functional Programming, 1997. [20] H. Pennington. Gtk+/Gnome Application De- velopment. New Riders Publishing, 1999. [5] M. Dalheimer. Programming with Qt. O’Reilly, 1st edition, april 1999. [21] C. Queinnec. Designing MEROON V3. In Work- shop on Object-Oriented Programming in Lisp, [6] K. Dybvig. Chez Scheme User’s Guide. Ca- 1993. dence Research Systems, 1998. [22] D. Remy´ and J. Vouillon. Obective ML: A sim- [7] M. Felleisen, R. Findler, M. Flatt, and S. Krishna- ple object-oriented extension of ML. In Sympo- murthi. The DrScheme Project: An Overview. sium on Principles of Programming Languages, SIGPLAN Notices, 1998. pages 40–53, 1997. [8] S. Finne and S. Peyton Jones. Composing [23] F. Rouaix. A Web navigator with applets in Haggis. In Fifth Eurographics Workshop on Caml. In Proceedings of the 5th International Programming Paradigm for Computer Graphics, World Wide Web Conference, in Computer Net- Maastricht, NL, September 1995. works and Telecommunications Networking, volume 28:7–11, pages 1365–1371. Elsevier, May [9] M. Flatt, R. Findler, S. Krishnamuryhi, and 1996. M. Felleisen. Programming Languages as Op- erating Systems (or Revenge of the Son of the [24] M. Sage. FranTk – A declarative GUI lan- Lisp Machine). In Int'l Conf. on Functional Pro- guage for Haskell. In Int'l Conf. on Functional gramming, Paris, France, 1999. Programming, Montral, Qubec, Canada, Septem- ber 2000. [10] J. Furuse and J. Garrigue. A label-selective lambda-calculus with optional arguments and [25] M. Serrano. Bigloo user’s manual. RT 0169, its compilation method. Technical Report INRIA-Rocquencourt, France, December 1994. RIMS Preprint 1041, Research Institute for [26] M. Serrano. Wide classes. In Proceedings Mathematical Sciences, Kyoto University, Octo- ECOOP'99, pages 391–415, Lisbon, Portugal, ber 1995. June 1999.

[27] J. Smart. wxWindows toolkit Reference Man-

© ¦§ ¤¢£ ©<& ¡ £! ¡¨ £¥ ¨£ , 1992. [28] T. Vullings, D. Tuijnman, and V. Schulte. Lightweight GUIs for Functional Program- ming. In Int. Symp. on Programming Languages, Implementations, Logics, and Programs, 1995. [29] K. Walrath and M. Campione. The JFC Swing Tutorial: A Guide to Constructing GUIS. Addison-Wesley, July 1999. [30] P. Weis and al. The CAML Reference manual. Technical Report 121, INRIA-Rocquencourt, 1991.