The Impetus

Notation is important. Our representations of ideas are not only what allow us to communicate with one another, but with ourselves. A good notation system is one of the most powerful conceptual tools we have. We humans often do well representing information. Mathematical notation's elegant mixture of layered symbolic abstraction and graphical suggestion has made the notation inseparable from the mathematical reasoning process. Musical notation conveys enough large-scale structure to make skimming a score quite informative, and enough detail to reproduce a piece of music from the score alone. Of course, we don't always do so well. Source code is a terrible way to represent the concepts of programming languages. Plain text conveys very small pieces of information well enough, but degrades as the scale grows. This is unfortunate, since the entire history of programming languages has been, roughly speaking, an effort to capture structure at ever larger scales and higher levels of abstraction. It's not too hard to get the gist of a dozen lines of code, but it's a royal pain to figure out even the most overall organization of ten thousand, even though that overall organization may be quite simple. We rarely use code to explain code -- ask a programmer to explain their code, and you'll probably get a diagram with some boxes and arrows. The powerful ideas of high-level languages suffer because we have to work with them through a low-level notation system. Textual source code is an anachronism, and although modern computers are hardly dumb terminals, we still design programming languages as if they were. Of course, there are many efforts to address the shortcomings of plain text languages, such as modeling tools, code browsers, and graphical component systems. Although these systems are commendable in many ways and can be quite useful, they all suffer from at least some of the following problems: Shadowing a more definitive but inherently less structured representation. Modeling tools attempt to represent a program nicely before it becomes source code; code browsers attempt this after. However, both are always out of sync by a compile cycle or even a design cycle, and always either end up playing catch-up to the changing source code, or smattering it with "GENERATED CODE -- DO NOT EDIT." The basic problem here is that the canonical form of a program is still the source code. Poor representation of information. The question of how to show programming language structures really well is still quite open. Research has few clear answers, and practice lags behind research substantially. Modeling tools generally do best on this front, but only scratch the surface of the problem. A good representation should integrate awarenesses of language design, graphic design, and the software development process. Awkward user interfaces. Code browser interfaces tend to look to standard widget sets for representing programs, with the result that they not only display structure poorly, but make changing it extremely awkward. A good system should make coding easier and faster than plain text -- even giving the option of using text where that makes good sense. Limited language domains. Most modeling tools and code browsers represent only a subset of the target language, making the graphical system at best a useful supplement to the text. Component-based systems like Java Beans can be more purely graphical and quite wonderful, but are not robust enough to replace languages as we know them now. A component's job is to abstract away all of the complex structure of a full-scale programming language to create very simple pieces a user can connect in very simple ways. This is fine and accomplishes truly wonderful things, but the components still rely on a more robust language as a foundation.

The Experiment

Eidola is an experiment to test the hypothesis that textual source code is anachronistic. It takes a radical approach to language design. A traditional language exists in an inherently unstructured textual form; a compiler translates it into a highly structured internal form, generates machine code, and then throws away all that useful structure until the next compile cycle. Eidola, on the other hand, starts and ends in the realm of mathematical structure, and these structures are independent of representation. From a traditional point of view, in Eidola the programmer is directly manipulating the parse tree, but a better way to think of it is that an Eidola program's fundamental form is structured in way that makes the distinction between source code and parse tree meaningless. In short, Eidola separates a program's structure from how that structure is presented. so that the structure is always accessible and flexible, and the presentation can focus on being a powerful, useful notation. The basic principles of Eidola are as follows:

1. The language's foundation is a clean, representation-independent formal semantics. 2. The structures of the formal semantics are the fundamental form of programs. 3. A layer of user interfaces form a notation system for these semantic structures.

Principle 1 (Semantics): Eidola's foundation is a clean, representation-independent formal semantics. The best way to present information well is to start with well-structured information. Any hope of representing well something as complex as a programming language lies in starting with the cleanest, simplest fundamental structure possible. Eidola's basic view of the world is a type-centric object-oriented model, backed by a formal semantics. The initial aim of the semantics is theoretical purity, not feature robustness; in other words, we're starting simple, and there are currently notable omissions. Principle 2 (Kernel): The structures of the formal semantics are the fundamental form of programs. This means that there is no single "true" binary form of an Eidola program; the canonical form is mathematical. Every memory representation or storage form satisfying the semantics is an equally legitimate form of a program. An Eidola kernel is a software implementation of the semantics, which can form the foundation of both editors and runtime environments for Eidola. Because a program always exists in the structured forms of the kernel, all static semantic structure is available at edit time. Principle 3 (Notation): A layer of user interfaces forms a notation system for the semantic structures. The kernel allows different interfaces to observe, query, and modify semantic structures. The kernel's responsibility is to manage the structure of a program; the interfaces' responsibility is to represent this information well and make it easy to change and work with. Different interfaces can observe the same element of a program; if one modifies it, all reflect the change immediately through an event mechanism. Thus, Eidola has no single correct or fundamental notation, and a programmer can view the same program through the lens of different representations for different kinds of insight.

Basic Terminology

The semantics is a formal mathematical description of the Eidola language. The semantics consists of fundamental structures, the basic units which define an individual program, and derived structures, which combine the fundamentals to give them meaning. A representation of Eidola is a mapping from the fundamental structures to some target domain, such that every legal Eidola program in the semantic domain has a representation in the target domain. A binary file format, a database schema, or a piece of software could all be representations. An Eidola kernel is a special kind of representation which enforces the rules of the semantics, allows interactive modification of the fundamental structures, and provides mechanisms for observers to track these modifications. A kernel will also likely want mechanisms for translating a program to and from other representations. A notation (or user interface) for Eidola is a way of presenting the structures of the language, and allowing a human to interact with a kernel. Since a programmer can use many notations simultaneously, a particular notation might not show all the structures of language (for example, it might show only type relationships). It also might show structures which are not strictly part of the language (like ordering and grouping of class members), but which help a programmer organize their thoughts.

To Learn More...

That's the experiment. If you find it interesting, you'll want to skim through the FAQ, and read about the current status of the project. There are links from there to other interest areas of the site.

Home	Copyright 2000-2001 Paul Cantrell