of Hypertext and Graphical User Interfaces

FLEX – A flexible extendable language

[Kay 68] M.Sc. thesis by Alan C. Kay, 1968 at the University of Utah

microfilm – University of Hannover MT3350

PDF scan

– an excerpt –

Table of Contents

I. Preface
II. Introduction
III. The Language Environment
A. Formalism
IV. The User’s Environment
V. The Pragmatic Environment
VI. Progress to Date


The FLEX system consists of merged “hardware” and “software” that is optimized towards handling algorithmic operations in an interactive, man-machine dialog.

The basic form is that of a hardware implementation of a parametric compiler embedded in an environment that is well-suited for semantically describing and pragmatically executing a large class of languages. The semantic language is called FLEX, includes the compiler-compiler as a string operator and is used as the basic medium for carrying out processes. It is of a higher-level nature and may itself be used for describing many algorithmic processes.

The machine itself is designed to be of the desk-top variety and sell at a low price. Because of these design parameters, many compromises in time and space had to be made to save money. The software system is implemented in read-only memory. To allow any possibility at all of debugging such a scheme, the algorithms involved were distilled down to their essence so that the entire system for the machine can be displayed (in flow diagram form) on a small wall chart.

In many senses the described system is a “syntax-directed” computer.

I. Preface

II. Introduction

[… FLEX] follows the traditions set by ALGOL 60 and several generations of EULER.

a. Calculation

[…] The expression is simply entered through the keyboard […]. Assigning the answer to the reserved word “display” indicates that the answer is to be returned to the CRT. At this level of use the entered FLEX code is executed statement by statement so that it acts as an interactive language. The “ ' ” is supplied by the processor and indicates to the user that FLEX is ready for input. […]

b. Variables

c. Decisions

d. The Use of Blocks as in ALOGOL 60

e. Extendability

New binary and unary operators may be declared giving the programmer powerful control over the language itself. For example, the functions max and min may be useful as operators, […]

FLEX may also be extended by either modifying itself via the compiler-compiler contained in the language or a wholly new language may be created using the same tools. […]

f. Comments

III. The Language Environment

A. Explanation of the Formalism Used


Semantics and Pragmatics

[…] Whenever possible, FLEX, itself will be used for description and, indeed, this is done in the SCRIBE chapter where FLEX is presented written in itself. […]

B. The FLEX Language



[…] SCRIBE is a super-set of the core language FLEX […]. SCRIBE has its roots in the “Floyd-Evans production scheme” and FSL. Basically it is a bottom-up, bounded context recognizer that uses FLEX as a sublanguage to express semantic relationships. […]

The Basic Elements of SCRIBE

1. Meta Declaration 2. Terminal Declaration Syntax 3. The Syntax Algorithm 4. Semantic Relationships


IV. The User’s Environment [p.64]


Most interactive systems use a special command language for handling files, initiating jobs and communicating with the compilers. In the FLEX system this language is FLEX – no other languages need to be learned. There are also no special entities called “files” in the system as will be seen.

Admitting the User to the Machine

When it is desired to allow a new user access to the machine, a process is created and named with his password. This process will not terminate during the period that he is allowed to use the machine. Most of the time it will lie passive on the secondary storage waiting to be reactivated which is simply done by the user typing in his password on the console.

The user’s process is activated, and he is now able to communicate with the machine through FLEX and the powerful editor which controls a free-running compiler that is translating everything that is entered through the keyboard to FLEX code. Since his process is also declared active, the pragmatic system will attempt to execute all produced code. This will appear to the user as though his commands at this lowest are being executed statement by statement.

By these means the user may entertain himself by performing calculations, editing text, generating new compilers, and generally going where his thoughts lead him. When he desires to cease running he simply types in a leave. This is the coroutine exit command and, since the routine which called him is the process scheduler itself, his process is passivated and the reentry point retained.

On the next day (or next week) when he again types in his password, his process is reactivated and control is passed to the reentry point; he is where he was the last time on the machine. This is why files (and file handling systems) are unnecessary on the FLEX machine. Any declaration he may have made (and possibly stored data in) have been saved to be used again.

Scope of the User

The user at the console is considered to be inside a process description which in turn is interior to the FLEX system and environment. This concept of system globality fits well the FLEX philosophy and provides a convenient means of allowing the user access to entities such as the FLEX language tables themselves, reserved identifiers whose meaning he may wish to redefine, etc.

V. The Pragmatic Environment [p.66]

1. Introduction

2. Segment and Process Control

VI. Progress to Date [p.98]


Two FLEX compilers have been programmed in ALGOL on the UNIVAC 1108 and have been running since mid-February 1968. Several partially successful attempts were made to combine the compilers with a number of the operating text editors at the University of Utah. The failures were partially due to the inadequacies of ALGOL as a real-time and process language in general, and in particular, to the very real defects of the UNIVAC version of ALGOL-60.

Implementation of the interpreter has been severely delayed for several reasons – the main one being that it took longer than expected to work out a rationale for a segmenting and swapping system that would work on such a small scale.

Current implementation is now taking place on an IBM 1130 partially because the machine can be dedicated most of the time to this task and partly also because it is small and does not tempt one into grandiose schemes.

Implementation on a PDP-10 is also being contemplated.

Future Expansion

The process-oriented nature of FLEX should make it an ideal kernel for numerous discrete simulation schemes.

A search for primitives in this as well as in the semantic transformation area is currently going on, and it is expected that some fruit will be available for plucking in the next month on this field of discourse.

Application packages are also being studied with a view toward both allowing FLEX to do something useful and providing a test-bench on which to evaluate the system. To this end, the solid-state circuit design program developed by W.R. Sutherland on the TX-2 computer at Lincoln Laboratories is being eye-balled. FLEX and LEAP (the implementation language at Lincoln) share some properties – notably the ability to store and retrieve associations – and it will be interesting to notice the difference between the 256k words of fast memory on the TX-2 versus 4 to 8k smaller words on the FLEX machine.




à propos

Incoming Links