Atomese is the concept of writing programs with atoms. It is a programming language, but not one intended for humans; rather, it is a programming language that algorithms and AI's can use. Its a bit verbose and ugly and complicated for humans, but is meant to be easy to manipulate, transform and re-write by software systems, including algorithms written in Atomese itself.
As a language, it borrows ideas from prolog, but with types, from SQL and relational algebra, but without tables, from functional-programming, but with the side-effect of being a graph database. It borrows ideas from intermediate languages, discarding the rest of the compiler. It is a graph-rewriting, term rewriting system with types.
Atomese was originally intended to be a language for knowledge representation (KR): that is, a way of encoding facts and hypothesis, in a machine-readable way, such that the knowledge can be manipulated, data-mined, reasoned with. This language subset was vaguely inspired by Prolog and Datalog. More correctly, it was constructed by layering concepts from mathematical logic onto a graph database: representing logical, symbolic statements as graphs.
Accessing data in the KR graph database required a query language, and as this was created and explored, concepts from relational algebra crept in: ideas from SQL, but without tables, or various concepts about graph query languages. These can be found in the GetLink and BindLink atoms. It is here where the query language (a pattern matching language) becomes closely tied to the concept of a graph rewriting system and a rule engine. Formally, the AtomSpace pattern matcher solves the subgraph isomorphism problem.
However, with increasing sophistication and usage, it was found to be convenient to add programming-language-like features to the knowledge-representation system. One motivation for Atomese was the need to implement procedural scripting and behavior trees within OpenCog -- that is, to define algorithmic snippets that could "do things" in the real world, such as turn robot motors and the like. This resulted in the appropriation of ideas from lambda calculus and functional programming, such as the LambdaLink, PutLink and FunctionLink. It resulted in an extensive type system, with many or most of the basic facilities provided by advanced type systems, such as F# or Agda.
Atomese is not, and was never intended to be a programming language with which humans would write "code", like they might with Java, Python, LISP or Haskell. Rather, it is a language that computer algorithms, such as term rewriting systems and rule engines, would be able to manipulate. It is a language that genetic programming systems, such as MOSES, could manipulate. It is a graph database that pattern mining algorithms could search, manipulate and transform. It is a language designed for easy self-introspection As such, it goes well beyond ordinary object reflection or metaprogramming, and provides an implementation of self-modifying code that is actually usable in ordinary machine-learning scenarios. All Atomese programs are always accessible as term trees, as a core design principle. As such, it resembles, in many ways, the intermediate languages found inside of compilers: the intermediate language is where a compiler can best "understand" the program, and analyze it's structure to perform the needed rewrites and optimizations.
As a runtime, atomese has horrible performance: it is many thousands of times slower than a native compiled language. For now, this is OK, because atomese was not meant to be a runtime; rather, it is meant for knowledge representation and self-introspection. Well, actually, that is not OK; this needs to be fixed. This is an open call for experienced compiler developers to join hands with experienced database developers and create a high-performance system for storing, querying and executing atomese. (So, at this time, Atomese is like the intermediate language in a compiler, but without any existing backed to assembly or byte-code.)
Despite this orientation away from human programmers, some exploratory work is being done on allowing human programmers to create Atomese more simply and elegantly. One idea is to syntactically sugar the Scheme or python shells for making Atomese more concise and transparent when coded in those languages. Another idea is to do something more radical, such as making an Agda Atomese, exploiting dependent type theory (Atomese has a relatively rich type system). Moving in a different direction, ghost allows authors to create chat subsystems that can control robot movements and respond to sensory input.
- Lucas Dixon, "Basic Elements of Logical Graphs", Lucas Dixon, CAM-CAD 2009. This paper describes how one might go about representing a logic as a graph. Although it is focused on a certain particular form of logic (intuitionistic linear logic), the overall ideas are generic, and can be used to expressed any kind of logic as a graph. Atomese already expresses generic logic as graphs; the Dixon paper can be read as an introduction to the general concept.
- Meta-Meta-Theory (MMT) as articulated by Florian Rabe & collaborators: See e.g. The MMT Language and System. This seems to be a system that is somewhat similar in philosophy and intent to Atomese. The actual written language of MMT is very different from Atomese, but its probably true that everything in MMT can be directly converted into Atomese. Unlike MMT, atomese is more focused on making room for probabilistic concepts. such as valuations consisting of multiple floating-point values. A direct comparison of the two would be excellent.