UIE - Creating a generic interface between Tcl/Tk and other languages: combining machine translation and concurrent programming.

Veronica Loell
gpl@nakawe.se
17 May 2003
Göteborg, Sweden.

The User Interface Engine

UIE stands for User Interface Engine, it is a theoretical software architecture that was designed to allow for communication between independent software modules.

The inspiration for the design came when I was trying to device a way to use a Tk-widget in a Paradox® application without resorting to creating and installing Active X controls. I finally decided that I wasn't going to just keep using a particular tool if it did not do the job I wanted it to do, on the basis that it was "the best tool for the job". There is in my opinion a good tool for every job. When you have a problem to solve that requires tools in different programming languages, on different platforms etc. is when you run into a problem. This is not in theory a difficult problem to solve. What I needed was the practical means for putting the theory into reality. The basis of the solution was Tclkit (http://www.equi4.com/tclkit). It provided easy access by scripting (Tcl/Tk) and platform independence. There are many additional strengths of Tclkit that I take advantage of but I will get back to them at some other time.

Having the tools that I needed to implement my theory, it was time to get down to the theoretical parts. Did I want just a way to do platform independent communication or was there something else that might prove useful for an architecture such as this? Isolating the actual source code in well defined small units should provide more stable code. Moving access to data from the source code should do the same. I work with database applications so my assumption on this part is that the data in the application is contained in one or more databases. Working directly with the user interface in its final graphical form to provide the appropriate responses to the users action will provide better overall grasp of the applications behavior, and methods to do introspection on actual running applications, as well as provide means for automatic documentation.

Incorporating these additional goals in my initial theory led me to the following definition of UIE (version 1.0):

  1. An UIE-application contains UIE-objects and UIE-functions.
  2. Objects and functions operate independently of each other.
  3. There is no direct communication between two objects or between two functions.
  4. There are two engines that serve as the glue to keep these parts together. The first engine is the UIE itself, the second is the data manager. The UIE is responsible for setting up and maintaining communication between objects. The data manager is responsible for supplying the objects with data.
  5. The objects communicate by means of message passing. These messages are given meanings to the objects by UIE-translators. These translators are specifically designed for each object. They translate a received message to some specific actions that are to be carried out by the object. They further help translate enquiries and requests, that the object want to convey to other objects, to generic messages that are in turn translated by the recipients UIE-translator.
  6. An UIE-application is event driven. Specific events for an object trigger different functions to be performed, or messages to be sent.
  7. The only part of an UIE-application that is allowed to change data is an UIE-function.

The theories behind UIE

The UIE is a combination of several different programming paradigms and software architectures. It is if you will my attempt to get the best out of all worlds. In the following sections I will briefly outline each of these. There may be others that I am unaware of, so this should not be seen as an exhaustive list.

Object oriented programming

In object oriented programming (OOp) the focus is on independent objects that work together to form an application. The UIE-objects are the result of this influence. The problem that I find with OOp is, that the functions and methods of the program are strictly bound to exactly one object. This severely limits the ways one may use to build an application.

Functional programming

The problem introduced by OOp is solved by the assumption in Functional programming (Fp) that functions are first order objects in the language. This influence results in the UIE-functions. I should note here that UIE-functions are not functions as in Fp or mathematics or even programming. A function always returns a value. A UIE-function never returns anything. Its result is either a change in the database or a request to the UIE to set up or modify a communication line. The name function is to be seen as something that provides some specific functionality for the application. With this I mean a high-level description such as "send an email", "add a new record to a table", etc.

Declarative programming

The UIE way is to work top down rather than bottom up. This means that one starts with a functionality specification, defining a set of functions (such as "send an email"), and then provide the implementation of these functions. As mentioned in the introduction, I wish to provide code that is modular and contained in very strict, small units. This leads to the scripting language used to provide the high-level descriptions of an UIE-application. It is an extendable language that consists of clauses in natural language rather than words stringed together by capitalizing or using underscores. I.e. "send email", rather than sendEmail or Send_email.

A UIE script is shorthand for a Tcl/Tk procedure. A script is also a page in a wikit (the script editor, http://www.equi4.com/wikit). The name of the page is the name of the script. The body of a page contains the actual script. UIE has 3 types of scripts, that are used for different things.

If you want to use arguments in the scripts, just include them in the name like: "name of script {arg1 arg2}".

Building the scripts in this way provides an abstraction at the same time as that abstraction automatically can be translated into the actual code that underlies it. This concept will probably become much clearer when one has a chance to look at the UIE-script editor. At the time of writing, it is not finalized, but it will be at the time of my presentation of this paper. It will be available from http://nakawe.sf.net

Concurrent programming and Machine Translation

Objects in the UIE communicate with each other by means of passing messages. These work much the same way as message passing in concurrent programming (Cp). In order to not have to define a "language" of messages between every 2 objects, Cp-message passing is enhanced by the concept of a "meta language" that one finds in theories of Machine Translation. The idea is to create a generic language, and provide functions to translate to and from this generic language for each specific language supported, such as English (en), Swedish (sv) and German (de). The point of this structure is to not have to create a translation for all of en-sv, sv-en, en-de, de-en, de-sv and sv-de. This means that for each additional language one will not have to double the number of existing translations. Providing a generic language results in having only to provide two additional translations for each new rather than providing a translation for each of the already existing languages.

Event driven programming

UIE-development is event driven, meaning that a specific event, caused by the user or the system, targeting one specific UIE-object will trigger exactly one UIE-function on that object.

A generic interface between Tcl/Tk and other languages

We have finally reached the subject set forth in the title of this paper, Creating a generic interface between Tcl/Tk and other languages. This section is very brief as it relies heavily on the preceding sections. There will at the time of my presentation, be a functional, ready to use, implementation of this interface, but at the time of writing it is not finalized.

Using the UIE to create a generic interface to/from Tcl/Tk consists of simply implementing the UIE, a translation engine for the Tcl/Tk side, and the framework for a translation engine for the other side. You might at this time consider the title misleading, since in effect what we are doing is creating the possibility, or a framework, for an interface that can be used with any programming language. In my mind this means that for any two programs or software components, irregardless of language and platform, one has only to provide a two-way translation to our "meta-language" for each component.

This paper and presentation have come about in a rather short period of time, and as such it will need to be accompanied by the examples I will provide at the time of my presentation, and probably some notes clarifying what I have written here. It is my hope that this paper nevertheless have provided enough information about the UIE for the reader to decide whether it is something worth learning more about.