Google/PSU Summer of Code

I have begun to fear that my initial description of Tern was unclear, as a result of attempting to explain to an unknown audience that Tern does absolutely everything under the sun, including what they want. There are two main confusions in that, and I would love to clear them up.

First, Tern does not do everything. Computers, being Turing complete, might be said to do everything, but in fact, they are just a general tool for running programs; all they do is run programs. The programs do everything. In analogy, Tern doesn't do everything---it is a very powerful, very general tool, but it is the set of patterns that defines what can be done. One of the central points of Tern is that Tern itself is simplistic, probably consisting of only one syntactical element. All the learning is figuring out the patterns and their relationships, and that is domain-specific learning, depending on what you want to describe.

Second, it would make a lot more sense to describe Tern separately to different audiences, rather than trying to pitch it the same way to programmers, patterners, architects, and everyone else who might ever want it. So, the remainder of this document is broken up into much more targeted sections. Read all that apply. Then read another, for a little perspective.

Tern for everyone

Everything exhibits patterns. Tern is a language for describing things based on what patterns those are. At its most basic level, Tern consists of two things:

• Tern itself is the syntax of the description language.
• Common Tern (after the common variety of the seabird) is a basic set of patterns that are always present, such as the Pattern pattern itself.

The normative forms of these two elements form the Tern standard, one of the deliverables of my project.

On top of the basics, other pattern languages can emerge, such as ones describing C (the Int pattern, the Struct pattern, the Procedure pattern...) or input/output (the Print pattern, the File pattern...). These patterns will interact; for example, translations from C patterns into I/O patterns might output a C program, for code generation. It is this exactly, combined with a HelloWorld pattern that abstracts the ubiquitous program, that will be delivered for the Summer of Code as the proof-of-concept use of Tern.

Finally, there is an interpreter. Actually, there can be any number of interpreters. An interpreter has its own atomic pattern language of things it can do. An interpreter that runs on a computer, for example, must ultimately boil everything down to instructions and system calls. All the translations to get there form a nasty web of NP problems, so for Summer of Code a simple computer interpreter will be submitted that just brute-forces its way through translating the HelloWorld example.

Like Go (the board game), Tern (the syntax) will take sixty seconds to learn, and Tern (the collective tool with all its pattern languages in all its domains) will take a lifetime (or two or three) to master.

Tern for programmers

For whatever your favourite programming language, there should be a pattern language in Tern that maps almost seamlessly onto it. So, feel free to write in whatever style you love!

As I expounded upon in detail in the original description, one of the main strengths of Tern is the ability to pick your own level of abstraction. So, if you're programming along, thinking like an objected-oriented programmer and talking really high-level talk, but suddenly decide this particular function needs to be hand-optimized assembly, that's no problem at all.

A lot of languages, particularly modern languages with their love of abstraction, fall into the ``Everything is an X'' pattern. In Java, for example, everything is an object. In pure-functional languages, everything is a function. In Tern, everything exhibits patterns. It's a general, powerful way of looking at things, because you can describe anything whose patterns can be described.

Tern for patterners

Tern isn't just for the programmers to describe their programs---it's for writing patterns. A complete Tern description is self-contained documentation, pattern language, and implementation. Instead of the amazing spread of different formats you use to explain your favourite pattern to your friend (GoF, Therefore-but, Alexandrian, etc.), tell them, ``Here, have a look at my Tern file.'' Tern will provide a standard syntax and set of patterns for describing patterns themselves, and it will be extensible so you never have to worry that having that standard will keep you from describing in your favourite way.

Tern for X

As I come up with them, more targeted explanations will arrive, and I'm sure I'll think of major editations to what's already here.

I hope this has clarified something. If you have any question, ask it, please!