©2001 by Singularity Institute for Artificial Intelligence, Inc.; All Rights Reserved.
Flare is a proposal for the first "annotative" programming language. In dialects of LISP, both the program and the program data are represented as lists. In Flare, the program, program data, and ideally the program state, are all represented as well-formed XML. Because XML is annotative (additional sub-elements can be easily added to any parent element without destroying the structural integrity of existing data) and extensible (new sub-element types can be easily created), these properties are shared by Flare objects and Flare programs. This fundamental idiom enables a wide variety of new patterns, and should enable significantly greater modularity, cleanness, ease of adaptation, and so on.
Jumping off the extensibility of XML, the flexibility of the underlying representation enables Flare to do several fundamental things in fundamentally different ways. Flare incorporates wholly new features, as well as several popular features of other languages which have never before been brought together. The current proposed design for Flare has many proposed features intended to increase cleanliness, modularity, and safety; some of them wholly innovative, others inspired by languages including Python, Java, C++, Eiffel, Common LISP, Scheme, Perl, MOO, Haskell, and more.
This page is intended for individuals who may be interested in becoming involved with Flare. The language specification hasn't been finalized yet, so if you have anything you think a new programming language desperately needs, now's a good time to speak up. We plan to begin coding in late August if at all possible.
This is a guide for programmers and is written in programmerese. It is not a formal introduction to Flare or anything; just a very rapid, informal, and incomplete list of some of the features and ideas that will go into Flare. The idea is that it shows you enough to determine whether you're interested.
The Flare project sometimes uses the present tense, even though no implementation of Flare exists, because it's too awkward to keep using the future tense. Just pretend this document came from a wormhole into the future.
Underlying Flare programs are represented as well-formed XML. Actual coding takes place in a language called FlareSpeak. FlareSpeak text can be conceptualized as an interface to the underlying FlareCode - the FlareCode is the model and the FlareSpeak is the editor. Because the FlareCode is the canonical, machine-readable form, the FlareSpeak GUI (1) need not be limited to plain text. It would even be possible to have multiple, different GUIs (FlareSpeak dialects) without sacrificing compatibility, since any conforming FlareSpeak GUI is required to be capable of displaying any valid FlareCode program. For example, one GUI might represent comments as text after a '#' symbol, while another GUI might represent comments as text in a different font, with the underlying FlareCode files remaining freely exchangeable. Similarly, an internationalized GUI might show keywords in Chinese or Arabic while still translating into canonical English for the underlying FlareCode program. The first implementation of FlareSpeak will almost certainly use plaintext or a close approximation thereof, however, and will probably most closely resemble the programming language Python in appearance.
Flare programs and Flare objects can be represented as XML, just as C++ programs can be represented as flat text, and LISP programs can be represented as linked lists. This doesn't mean that writing an XML parser is the same as writing a programming language, any more than implementing a linked list is the same as inventing LISP.
However, XML is far more flexible than the current alternatives for representing programs and objects. Currently, there's flat text (C, C++, Java, Perl, Python), machine code (for compiled programs), or linked lists (for LISP programs). All of these representations share the property that it is hard to add new data without disrupting existing data.
In Flare, both programs and data are tree structures in which new elements and new element types can be easily added without disrupting the integrity of existing data. All elements have metadata and all elements can have subelements. That makes Flare an annotative programming language. It so happens that there is a widely accepted standard for representing these tree structures as text files containing a lot of <angular> <brackets>, but that's pure gravy. Likewise the fact that so much of the programming universe is moving towards XML, creating an enormous niche ready-made for Flare.
Example:
An object of type 'human':<human>Can be annotated by the 'society' library module with an element describing social status:
<name>Bob</name>
<hands>2</hands>
<legs>2</legs>
<age>35.23</age>
</human><human>This shows several idioms of Flare:
<p-society>
<status>19</status>
</p-society>
<name>Bob</name>
<hands>2</hands>
<legs>2</legs>
<age>35.23</age>
</human>The FlareSpeak code to make this annotation, and another annotation describing "rank", might appear as follows:
- Objects and data, like programs, are represented as XML.
- Flare uses a namespacing idiom to assign metadata to Flare elements. If the <human> object is known to have metadata from a class defined in the "people" module, then <hands> and <legs> can be known to have the metadata that indicates they are instance members of class "human". This metadata, in turn, informs the Flare interpreter that <hands> and <legs> are expected to have numeric content, and that the internal content of <hands> is therefore the integer 2 rather than the string "2".
- The annotation made by the "society" module is placed within a safe "planar data" element, and will not appear to other modules as an instance member of Bob. Even the original "people" module that defined Bob will not see the annotation unless specifically looking for planar data. This namespacing mechanism increases modularity and prevents modules from stomping on each other's annotations.
- It is equally easy to annotate an object, an instance member of an object, or another annotation. Everything is an XML element and every XML element can be annotated.
- Within the planar data for "society", <status> has the metadata assigned to the "status" tag by the "society" module. In this case, <status> contains numeric content. If "status" were instead an object class, then the <status> element inside <p-society> would be an object. Thus, annotations made to a Flare object can contain arbitrarily complex object-oriented data, which will be understood as first-line objects by the interpreter.
# Some code appearing in module "society"
person%.status = 19
person%.rank = ranks.military.captain
# 'person' is a local variable already containing a reference to Bob.
# 'ranks' is a global variable for this module
# foo%.bar is the idiom for local planar access
# The idiom for nonlocal planar access would be person%society.status
Some languages, such as Perl and Python, have objects which can contain arbitrary key-value pairs, and it therefore looks at first glance like it ought to be possible to write simple annotative code in Perl or Python. But even the above sample (and never mind all the features described in Idioms of Flare) shows several things that Flare does in a fundamentally different way.
There's a universal access idiom for metadata.
Metadata can also be annotated.
The metaphorical "keys" of the metaphorical "key-value pairs" - the
XML tags that set apart an element - have metadata, not just objects.
It's possible to annotate an annotation.
It's possible to annotate a variable or instance member whose value
is a plain old number, rather than an object or a hash.
Suppose you want to perform an annotation in Python:
# Python code:There are, immediately, several problems. First of all, you can't retrieve metadata on "foo.annotation", or for that matter, "foo.populace"; as far as the interpreter is concerned, "populace" and "annotation" are simple text strings, the keys in key/value pairs, and have no meaning within the class hierarchy. Languages with static typing, such as C++ and Java, which allow pre-declared instance members to have some metadata, typically don't allow dynamic annotations; all instance members must be declared in advance.foo = SomeKindOfObject(3) # consequence: foo.populace == 3
foo.annotation = 5 # This looks like an annotation.
The second problem: You can't annote (2) the "annotation" property because it's a number instead of an object; you'd need to convert the annotation to a Number object first, or something. If foo.annotation is an object reference, there'd be no way to annote "foo.annotation" specifically, instead of annoting the object itself (which may be referred to elsewhere).
A third problem is that there's no namespacing mechanism or planar data, meaning that any reflective Python code may wind up thinking that the annotations are supposed to be a part of the object, and that a module which makes annotations called "annotation" can very easily stomp on a class that already defines an instance member called "annotation".
One can imagine writing a global dictionary in which it is possible to look up "annotation" to find the metadata stored on it, or better yet, looking up the metadata for "annotation" in a dictionary that is unique to the SomeKindOfObject class. One can imagine a standard where "foo.annote_annotation" is an annotation on the annotation. But at this point, you're getting into the territory of reinventing Flare, badly. The interpreter won't know that you think "annotation" has metadata, so if the metadata has any meaning, it will only be in code that you write - in fact, only code that you write will even know where to look for the metadata. If you want to be able to annote annotations, or annote anything that isn't a Python object, you'll need to basically rewrite all the code in question to use first-line objects in order to allow for annotations.
So, trying to write Flare code in Python - or any other non-annotative language - is like trying to write C++ code in C, if not worse.
To write a C++ program in C, one must, at best, write:
(*reinterpret_cast<INSERT_FUNC_PTR>(instead of
item->vtab[INSERT_FUNC_INDEX]))(object, index)
item->insert(object, index)Maybe you can hand-code your virtual function tables, hand-code the lookups, and hack up some C++-like libraries to handle things like inheritance and so on... but it still won't be the same experience as writing in C++. You can always write the low-level elements of a high-level language as high-level structures in a lower-level language, given time and patience. However, a high-level structure in a high-level language generally cannot be developed in any simpler form. High-level language features must be implemented directly to ensure ease of programming idiom, standardized interoperability with other code, and compatibility with the language libraries.
Of course, you may find that even knowing what Flare is like forces you to write sort-of-Flare programs in Python and C++... once you have seen the light, you can never go back.
Flare will be the first annotative programming language. Annotative programming, if done properly, has the potential to be the successor to object-oriented programming, in the same way that object-oriented programming succeeded procedural programming, procedural programming succeeded assembly language, and assembly language succeeded raw hexadecimal numbers. (This is a big claim, but it may sound more plausible after reading Idioms of Flare.)
Annotation is, fundamentally, a part of the way the human mind works. Each time we move closer to the way the human mind works (3), we get a fundamental improvement in programming language. We think in process descriptions rather than sequences of machine instructions, which is why structured programming is an improvement over assembly language. We think in terms of objects and behaviors, and categories that inherit characteristics from their supercategories, which is why object-oriented programming is an improvement over structured programming. And we also tend to note lots of facts about both objects and categories, and then make decisions elsewhere based on previously noted facts, which is why annotative programming is an improvement over object-oriented programming. Flare is a higher-level language, where higher-level means closer to the human mind.
Accordingly, we have hopes that Flare will be a big hit.