A Graphical Toolkit in LIFE
Contents
1. They are functions taking two boxes as arguments and returning the smallest box containing these arguments placed in a certain way For instance Boxl 1 above Box2 returns the smallest box containing Box1 and Box2 such that e Box l is above Box2 and e their left sides are aligned Containment Boxl contains Box2 expresses that Box1 contains Box2 If no size is specified for Box it will be given the same size as that of Box2 If Box1 has a border feature worth Border it will be used to reserve a space of that width around the box In this case Box1 will be larger than Box2 Refined positioning There are also some primitives that set finer constraints For instance Boxl lr_aligned Box2 will force the left side of Box1 to be aligned with the right side of Box2 Boxl cc_v_aligned Box2 will force the centers of Box1 and Box2 to be vertically aligned Sizes of boxes It is very useful to be able to constrain some boxes to have the same size same_size List_of_Boxes will force all the boxes of the list to have the same height and width When boxes contain text their sizes are computed on the fly using a subsort of box t_box If no size is already given for a box and if it is a subtype of t_box then its size is computed according to the text the font used and the space to be reserved around it which are declared as features of t_box These constraints may be cumulated and imposed in any order The local constrai2. the term s root variable and t is an untagged w term An untagged w term is either atomic or attributed An atomic term is a sort symbol in S An attributed term is an expression of the form s ee ee A where the root variable s sort symbol s S and is called the 2b term s principal type the s are mutually distinct attribute symbols in F and the t s are terms n gt 0 Variables capture coreference in a precise sense They are coreference tags and may be viewed as typed variables where the type expressions are untagged Y terms Hence as a condition to be well formed a term must have all occurrences of each coreference tag consistently refer to the same structure For example the variable X in person id gt name first gt string last gt X string father gt person id gt name last X string ON refers consistently to the atomic term string To simplify matters and avoid redundancy we shall obey a simple convention of specifying the sort of a variable at most once and understand that other occurrences are equally referring to the same structure as in person id name first gt string last gt X string father gt person id gt name last gt X In fact since there may be circular references as in xX person spouse gt person spouse gt X this convention is necessary Finally a variable appearing nowhere typed as in junk kind gt X is implicitly typed b
3. which will be extensively used in the following to express placement constraints between objects Another important application of this suspension mechanism is the ability to mimic concurrent processes that may communicate thanks to the logical variables Consider for instance the two functions process_i 1 NX Y gt process_1 NX NY Y process_2 2 NY X gt process_2 NY NX X 2 NY 1 NX with the query process_1 X Y process_2 2 Y X The execution first suspends process_1 since its arguments are not sufficiently instantiated Then it calls process_2 which can be executed Its execution first suspends the recursive call to process_2 then binds X to 1 NX By doing this the call to process_1 will be released and its execution will suspend a new call to process_1 and release the suspended call to process_2 Thus we have two processes synchronized thanks to their arguments This mechanism is used in the toolkit to deal with events An event handler is a recursive function that waits for events is released when an event occur and reinstalls itself after having performed the right actions 3 A Graphical Toolkit in LIFE As we have seen in the introduction the toolkit we describe now is organised around three concepts boxes constructors and looks These three concepts are represented by sorts in the For convenience LIFE adopts the list syntax of Prolog The notation A B is syntactic sugar for the te
4. 1s only 2200 lines long The main limitations of this prototype come from the speed limitations of the LIFE interpreter itself and the number of available functionalities of the basic X libraries interfaced with LIFE Nevertheless it should be very easy to extend This toolkit has been used with great ease to build the X interfaces of some of the example programs of the LIFE system One can retrieve the system and use it from the World Wide Web URL http www isg sfu ca life References 1 Hassan Ait Kaci A Lattice Theoretic Approach to Computation Based on a Calculus of Partially Ordered Types PhD thesis University of Pennsylvania Philadelphia PA 1984 2 Hassan Ait Kaci An algebraic semantics approach to the effective resolution of type equations Theoretical Computer Science 45 293 351 1986 3 Hassan Ae Bruno Dumant Richard Meyer Andreas Podelski and Peter Van Roy The wild life handbook a user manual Technical report Digital Equipment Corporation Paris Research Laboratory Rueil Malmaison 1994 prepublication edition 4 Hassan Ait Kaci and Roger Nasr LOGIN A logic programming language with built in inheritance Journal of Logic Programming 3 185 215 1986 5 William F Clocksin and Christopher S Mellish Programming in Prolog Springer Verlag Berlin Germany 2nd edition 1984 6 Richard O Keefe The Craft of Prolog MIT Press Cambridge MA 1990 13
5. A Graphical Toolkit in LIFE Bruno Dumant Hassan A t Kacit April 12 1995 Abstract LIFE is a programming language integrating different programming paradigms in the same framework such as object orientation concurrency and passive constraints We have used this language to implement the prototype of a very basic and simple graphical toolkit for LIFE applications This prototype is built on top of a basic interface between LIFE and the X Windows library It demonstrates that the combination of the different paradigms supported by LIFE is most adequate for designing such applications Because the toolkit is all realized in LIFE it could be easily ported to another window system e g MS Windows provided the basic calls to the underlying window system are given as interface 1 Introduction LIFE an acronym for Logic Inheritance Functions and Equations is an experimental programming language designed after these four precepts for specifying structures and computations 3 _ LIFE can also be seen as a specific instantiation of a Constraint Logic Programming CLP scheme with a particular constraint language in its most primitive form this constraint language constitutes a logic of record structures In this paper we mean to overview informally the functionality of LIFE and the conveniences that it offers for programming and describe a simple toolkit to build interactive window based applications in LIFE It provides the user with som
6. Consider for example the poset displayed in Figure 2 and the two terms In fact if a first order term is written f ti f it is nothing other than syntactic sugar for the w term JSS diesa ty 164 4 Si fe i Px ee GF Figure 2 A lower semi lattice of sorts XxX student advisor gt faculty secretary gt Y staff assistant gt X i roommate gt employee representative gt Y 1 and employee advisor gt fy secretary gt employee assistant gt U person roommate gt V student representative gt V helper gt wy spouse U Their unification up to tag renaming yields the term W workstudy advisor gt f secretary TA workstudy representative Z assistant w roommate gt Z helper gt w spouse W Last in this brief introduction to the calculus we explain type definitions The idea is that types in the signature may be specified to have attributes 1n addition to being partially ordered Inheritance of attributes from all supertypes to a subtype is done in accordance with term subsumption and unification For example given a simple signature for the specification of linear lists S list cons with lt list and cons lt list this is expressed as lt list cons lt list In addition it is possible to specify that cons has an attribute 2 gt list This is expressed as econs 2 s gt List In fact it is possible to attach
7. complex properties attributes or arbitrary constraints to sorts These properties will be verified during execution and also inherited by subsorts A definition attaching attributes to a sort 1s expressed using the following syntax sort label gt w term label gt w term For example to express that vehicles have a make that is a string and a number of wheels that is an integer we may write vehicle make gt string number_of_wheels gt int And to say that cars are vehicles that have 4 wheels we write car lt vehicle a car number_of_wheels gt 4 Obviously if the relation car lt vehicle is asserted then any properties attached to car must be compatible with those attached to vehicle otherwise type car would be L It is also possible to use functions in attribute definitions for example square side gt S real surface gt S S One can also demand that certain constraints always hold about a sort The syntax for this is sort attributes constraint where constraint has the same form as that of a definite clause s body The operator is pronounced such that For example code key gt S string pretty_complicated S attaches a constraint to any object of sort code where pretty_complicated is a predicate expressing some property on strings You might find it helpful to read this as all codes have a key that is a string S such that S is pretty com
8. concurrent processes Communication with X is handled by the xGetEvent function This function takes two arguments a window and a mask and suspends until an event matching the mask occurs in the window catch_events Button gt true Event get_event handle_event Event handle_event mouse_event gt true actions Event get_event handle_event Event text field_l Figure 3 text field look Events are implemented as sorts mouse_event expose_event An event handler is implemented as a recursive function that performs some actions when an event of the proper sort occurs and reinstalls itself afterwards 3 3 Looks The look of a box is also handled through inheritance For instance the sort describing the appearance of a text field text_field_l is a subsort of text_box field and frame each of these sorts describing a special look feature The idea is to have specific types to which some specific drawing methods are attached As there is no such thing as overriding in LIFE inheritance is not handled as usual Drawing methods are described thanks to two predicates draw_static and draw_dynamic draw_static is just used once when the box is drawn for the first time draw_dynamic is used each time the state of the widget changes to redraw it according to its new State A special control mechanism is used to draw widgets It is important here to make sure that all the drawing m
9. e basic functionalities of bigger toolkits in short the ability to use buttons text fields menus and sliders Composite objects containing these primitives can be created arbitrarily at run time The prootype toolkit is built on top of a basic X interface that consists essentially in calls to the X library The toolkit is organized around three concepts boxes looks and constructors e boxes are used to compute the sizes and positions of objects on the screen INRIA Domaine de Voluceau Rocquencourt B P 105 78153 Le Chesnay Cedex France Bruno Dumant inriafr Simon Fraser University School of computing science Burnaby British Columbia V5A 186 Canada hak cs sfu ca 7 161 e constructors are used to build and initialize screen objects All objects that have a behavior 1 e not simple graphical objects but real widgets inherit from one constructor type e looks are used to describe the appearance of screen objects An object may be a subtype of several look types and will inherit the appearance of these looks In the next section we give an overview of the LIFE language then we shall focus on the toolkit and describe its implementation 2 The LIFE language LIFE expressions are of three kinds functional relational and structural The function oriented component of LIFE is directly derived from functional programming languages with higher order functions as first class objects data constructors a
10. ethods defined for a look will be used each time it is necessary To do this the drawing predicate calls draw_static and draw_dynamic with matching and not unification and backtracks until no method can anymore be used 3 4 Screen objects The screen objects manipulated by the X toolkit are subsorts of looks and or constructors They usually have an additional feature that stipulates how the states of the look and that of the constructor are linked change_state All these mixed paradigms make it very easy to design interfaces It is also very easy to add new objects to the toolkit For instance a user that wants to define a slider that contains text can do it easily this way my_Slider lt h_slider_c my slider lt frame my_slider lt field 11 171 my_slider lt text_box These declarations just stipulate that my_slider has the behavior of an horizontal slider and the look of a frame a field and a text box Now imagine the user wants to use it in an interface where the value of a text field is related to that of the slider and the text DANGER must appear on the slider if the value is too big This will be turned into the following code make interface Panel Button text field button text gt 100 action gt set _slider Button Slider SlideBar slide_bar width gt 200 contains Slider my_slider min gt 0 max gt 100 text gt DANGER action gt set _text Slider Button Pa
11. ke data structures in logic and functional programming more adequately than first order terms do without loss of the well appreciated instantiation ordering and unification operation Let us take an example to illustrate Let us say that one has in mind to express syntactically a type structure for a person with the property as expressed for the underlined symbol in Figure 1 that a certain functional diagram commutes The syntax of terms is one simply tailored to express as a term this kind of approximate 162 gt OAE E E E E S Figure 1 A commutative functional diagram description Thus in the calculus the information of Figure 1 is unambiguously encoded into a formula perspicuously expressed as the term i X person name gt id first gt string last gt S string spouse gt person name gt id last gt S spouse gt X It is important to distinguish among the three kinds of symbols participating in a term We assume given a set S of sorts or type constructor symbols a set F of features or attributes symbols and a set V of variables or coreference tags In the w term above for example the symbols person id string are drawn from S the symbols name first last spouse from F and the symbols X S from V We capitalize variables as in Prolog A w term 1s either tagged or untagged A tagged w term is either a variable in V or an expression of the form X t where X V is called
12. nd algebraic pattern matching for parameter passing The convenience offered by this style of programming is one in which expressions of any order are first class objects and computation is determinate The relation oriented component of LIFE is essentially one inspired by the Prolog language 5 6 Unification of first order patterns used as the argument passing operation turns out to be the key of a quite unique and hitherto unusual generative behavior of programs which can construct missing information as needed to accommodate success Finally the most original part of LIFE is the structure oriented component which consists of a calculus of type structures the w calculus 1 2 and accounts for some of the multiple inheritance convenience typically found in so called object oriented languages The next subsection gives a very brief and informal account of the calculus of type inheritance used in LIFE calculus The reader is assumed familiar with logic programming 2 1 Calculus In this section we give an informal but informative introduction of the notation operations and terminology of the data structures of LIFE It is necessary to understand the programming examples to follow and the description of the toolkit The calculus consists of a syntax of structured types called 7 terms together with subtyping and type intersection operations Intuitively as expounded in 4 the calculus is a convenience for representing record li
13. nel panel contains Button c_left_of SlideBar set_slider Button Slider Value parse Button text cond Value lt real cond Value gt Slider min and Value lt Slider max move_slider Slider Value check_danger Slider set_text Slider Button Button text lt lt int2str floor Slider value refresh_look Button check_danger Slider cond Slider value gt 80 Slider text lt lt DANGER Slider text lt lt refresh _look Slider make_interface defines the layout of the interface and its objects The text in the text field resp the position of the slider is modified by set_text resp set_slider when the position of the slider the text is modified Both call check_danger that changes the text of the slider according to its value 4 Conclusion We have shown in this paper how the different programming paradigms of LIFE may be used to simplify the design of the basic mechanisms of a graphical toolkit Constraints are used to deal with the placement of boxes inheritance to deal with the looks of widgets suspension to easily design event handlers The central data structure of LIFE the term seems to be really i oe 12 well suited for the modelling of objects such as those needed in graphical interfaces What has made this toolkit so easy to build is the simultaneous presence of these paradigms in the same language To give an idea of the conciseness of the implementation this toolkit
14. nt propagation of LIFE guarantees that if the constraints are consistent and enough information exists to determine a placing it will be determined If the constraints are inconsistent then they will fail and cause backtracking 3 2 Constructors Describing the behavior of widgets 3 2 1 Constructor types A constructor type defines the behavior of a family of widgets and defines the methods to initialize them by creating the windows and setting up the event handlers Let us take the example of the constructor of text field widgets It is defined as follows text_field_c lt box A text_field_c on gt bool text gt string action gt Action constructor gt build _text_field A The on feature determines the state of the button text its text action the action to be performed when a new text is entered and constructor the method used to actually create a text field Creating a text field consists in initializing the first features creating a window and setting up an event handler for this window build_text_field Button create_subwindow Button Button on lt lt false initialize _action Button Initialize text Button catch text _field_events Button Button on designates the on feature of Button The lt lt sign is a permanent assignment which means that this value won t be modified on backtracking 3 2 2 Handling events Events are handled thanks to the ability of LIFE to express implicitly
15. plicated In fact the such that operator may be used not only in sort definitions but as with arbitrary terms in functions and predicate definitions It is a function in that the expression E G pronounced E such that G evaluates the expression E then proves the goal G and finally returns the value E in the G s solution context For example the w term conjunction operator amp is defined as the following infix function Rik YS ey 2 2 Functions and suspensions in LIFE In LIFE a basic term denotes a functional application if its root symbol is a defined function An example of such is append list L where append is the function defined as append L list L append HIT list L list gt Hlappend T L The w term foo bar gt X list baz gt Y list fuz gt append X Y is one in which the attribute fuz is derived as a function of the attributes bar and baz Unifying such w terms proceeds modulo suspension of functional expressions whose arguments are not sufficiently refined to be provably subsumed by patterns of function definitions For instance the equation X append Y Z will be suspended until Y is bound to a term subsumed by or lis and Z by a term subsumed by list Arithmetic functions in particular are implemented as functions that will suspend until their arguments are bound to numbers This gives the power of passive constraints to the language
16. rm cons A B which is itself a shorthand for the term cons 1 gt A 2 gt B process_Il process_2 release k a implementation which we detail in the next subsections 3 1 Boxes and placement constraints 3 1 1 Definition of boxes The basic concept used in this toolkit is that of a box A box resembles very much the box concept used by TeX They have been introduced in the toolkit to let the developper of an application describe simply the position constraints between the objects of the interface The passive constraints of LIFE are then used to compute the actual position parameters of the boxes satisfying these constraints All the objects manipulated by the toolkit are boxes A box is defined by the following type declaration box X Y width gt Dk nei che gt DY border gt B X and Y are integers giving the coordinates of the box DX and DY are integers giving the dimensions of the box The border feature is the width of reserved space on each side of a box When a box is declared the user need not specify all these parameters Some of them have customizable default values others may be computed thanks to constraints defined over boxes We describe in the following the basic constraints offered by the toolkit These primitives just set and try to resolve the placement constraints 3 1 2 Constraints on boxes Relative positioning The toolkit offers a number of primitives to place boxes
17. y a special greatest initial sort symbol T always present in S This symbol will be written as the symbol as in age integer name gt string In the sequel by w term we shall always mean well formed 7 term Generalizing first order terms w terms are ordered up to variable renaming Given that the set S is partially ordered with a greatest element T its partial ordering is extended to the set of attributed terms Informally a term f 1s subsumed by a term tz if 1 the principal type of f is a subtype in S of the principal type of t2 2 all attributes of t are also attributes of ti with w terms which subsume their homologues in f and 3 all coreference constraints binding in 2 must also be binding in f For example if student lt person and paris lt cityname in S then the 7 term student id gt name first gt string last gt X string lives at gt Y address city gt paris father gt person id gt name last gt X lives_at gt Y is subsumed by the term person id gt name last gt X string lives at gt address city gt cityname father gt persont id gt name last gt X In fact if the set S is such that greatest lower bounds GLB s exist for any pair of type symbols then the subsumption ordering on term is also such that GLB s exist Such are defined as the unification of two w terms A detailed unification algorithm for terms is given in 4
Download Pdf Manuals
Related Search