 Welcome to Emerging Languages Camp 2010, Third by Phil McCurrio. Good morning. Today I'm going to present Third, an experimental language that developed as proof of concept and as a research tool. I also just realized this is the third talk. I don't know if you guys planned it that way. The motivation is a minimalist visual language, as simple as possible. Programming is as much as possible via direct manipulation, so it would work well in a low-typing environment like a tablet or a pen-based machine. Visualization of code execution as part of debugging. The notion of code behind the interface. I won't be able to talk too much about this unfortunately, but that's the notion that, given the user interface element, you can navigate from there to where the code controls that element is. And also self-modifying or reflective visual language specifically as far as that might be interesting in implementing machine learning. I'll talk about that really again. So Third is a stack-based interpretive language. It's functional, concurrent, visual, and reflective. I'll talk today about prior work a little bit. Then I'll present the key concepts in the language. I'll concentrate on four example programs, and then I'll talk about the future work a little bit. Down the bottom is a link to a paper that corresponds to this that has what I'm talking about today. The user interface in Third was inspired by small talk, just like everybody else, and self, both very minimalist systems. Also systems demonstrating inspecting and modifying code within the interface. And down here, Boxer, which was developed in the early 80s at UC Berkeley. It demonstrated hyper-programming of code as hypertext in less than boxes, and also the notion of code behind the interface is really where I got that from. From the spreadsheet, I've stole the notion of the grid as both user interface and data type. You can also argue that Excel is the most popular programming language currently in the US. Other systems that stretch the spreadsheet paradigm one way or another. ThingLab, spreadsheet 2000, Forms 3, RISCELL, and Subtax, which we'll be presenting here about tomorrow. From the language point of view, Third is both like fourth. Just got it. It's very minimal language. It's also like Joy, which is the functional cousin of Fourth. The cousin of Fourth adds functional to the framework model. And the FUNGE, and other two-dimensional programming languages. Third is essentially a FUNGE, but hopefully it's a little bit more readable. The fundamental unit in Third is the CELL. The CELL may or may not be located in the grid, it may have neighbors. A CELL can either be atomic, in which case it has a single textual value. And in Third is a string. But CELLs do have types associated with them. The types are used to control how the value is interacted with and displayed. It doesn't constrain the value. Everything is a string. Non-atomic cells contain a grid of subcells. The grid expands as needed. Not all locations have to be filled. This is two-dimensional, but conceptually it could be extended to more dimensions. The entire space of cells is called Third Space. And there's one root cell at the top, which is referred to as slash. Everything else is contained under that cell. This is how Third displays a grid as a table, by default. You can see here what looks like the unit's path name. This is the path to this cell from the root of Third Space. Each cell also has a unique ID. Neither one could be used to refer to a cell. This is zoomed in on a single cell. You can select the type of the cell from a drop-down menu. When you view a cell on grid, they're all viewed as text. All types are viewed as text, except for opcodes or instructions in the language, which are viewed as icons. But if you zoom into them, even an opcode is just text. It's just text that's been marked as executable. All types, like integers and reels, can take parameters, specifying in this case the low, high, and step value. Or if you have a choice of strings, you can specify a list of values for that. Now when I turn on the user interface panels, you can see that a string is edited in this text. The number is edited using spin box, and the choice becomes a drop-down list. These are the default panels, custom panels. By inspecting the panels, you can find out the code underneath from the code behind the interface. Within a grid, you can specify a sub-cell by its coordinates. The coordinates begin with zero, and have the y-axis horizontal and the j-axis vertical in this display. So that cell outline in green here, contains the word two, can be indexed as two-one. If the j-value is not specified, it defaults to one, unless i is zero. So the same value can be indexed as simply two. This mechanism of defaulting of values means that indices means that you can expand this beyond two dimensions. The cells that are i equals zero or j equals zero are called the frame cells. This is, for example, a cell zero zero doesn't exist. The rest of the cells are the context cells. If the frame cells contain text, if they exist and contain text, they can be used to index into the context cells. So this same cell can be indexed as beta English, or simply as beta. This addressing scheme makes a third grid, essentially a general data type, a union of a variable that's just a single value. A list of values can be indexed numerically. Add the i frame in, and you get a dictionary. Add the j frame in, and you get a relation or table. And a hierarchy can be represented using containment. You can also get from one cell to another cell using relative paths. Starting out at this cell here, the path dot dot refers to the containing grid cell. Plus one, plus zero refers to the cell immediately to the east, minus one, plus one refers to the cell immediately to the southwest. And there's also a notation here that allows you to refer to a cell that doesn't exist. Plus plus. For relationships other than containment, cells can be bound together in triples called triads. And this is also where the name third comes from. Combine cells together in threes. The three corners of a triad are called A, B, and Y. They're represented as three paths into third space. And I like to think of it as a directed labeled graph, where A is the head, B is the tail, and Y is the label. So this entire network of triads is essentially a directed labeled graph where the labels can participate as nodes in the graph. When viewing a cell, you can choose to show the triads. And this cell has one triad, and these are the other two corners of the triad that's attached to it. Each of those are quarters that navigate to those cells. So in summary, a cell is a location for a beautiful value in third space. It specifies its type and its relationship to other values. One of the things that you can use triads for is attributes, specifically for attaching code to a cell. A cell could be attached as either a formula or as an event. In either case, the cell that we attach to is called an anchor cell. Or some type of a cell itself. If it's attached as an event, then each time I change the anchor cell, the code gets executed. There's no other time. This code has to be implementing a value in the last cell. A formula is more like a spreadsheet formula. The value of the computation, the result of the computation is stored in the anchor cell. And each time you change something, the formula gets revaluated in the cell. Each formula or event has a wave of execution associated with it. This is the wave viewer down here. It's kind of a cluttered display. A focus down here, there are four data stacks, three data stacks and one execution stack. Code begins when a cell is pushed onto the execution stack. Since that cell contains a value that's not an opcode, it's simply popped and pushed onto a data stack when it's executed. We then follow a list of relative paths to find the next cell to execute, called the next route. The default route is left to right top to bottom. So we find this next cell contains seven and we push that onto the X stack. That completes one cycle. X is executed by popping it and pushing it onto a data stack. We then follow the route again and find the multiplication opcode. When that's executed, it multiplies the value, leaves the answer on the stack. We try to find another cell, we fail, we get one end opcode pushed onto the stack for us by the system. And when the end is executed, it pops the value at the top of the A stack and use that to set the value and the type of the result. In order to implement higher order functions, we need to be able to quote code when we do this by pushing it into a grid. So these two programs are identical or equivalent. The bottom one, when it's executed, it pushes a six, it pushes this grid, and then the evaluate opcode, pops the grid, takes the first cell, pushes it on the X stack. And it goes. So this is the first program I want to show. This is an average computation. In the middle is the anchor cell for the result. The bottom is the formula and the top is the input. Each time I execute, each time I change what the value is in the input, the formula gets computed and the result changes. This code begins by referencing the input cell and making a copy of the reference. And then it uses the higher order function fold, which is like reduce in the MapReduce paradigm, to fold in the addition operator into the list, producing the sum of the values in the list. Then we step through the list, incrementing this value here to get the count of the values in the list. We divide, set the type, and we've got the average. This is the second program right here. This is the first simple thing I can come up with that demonstrates reflection. At the top we have the anchor cell oscillating between minus 2 and plus 2. The program begins by referencing a cell called the heartbeat that's constantly changing. It then drops that value, but because it referenced that cell, every time it changes, the formula gets revalued. We then get the anchor cell and either incremented or decremented. If you watch that, you can see the program is rewriting itself over and over again. Changing that tweaking with the decrement is against the values. For a more practical example, we have 99 bottles of beer on the wall. I'm holding 9 here because that's all that fit on the slide, but in fact, the number is controlled entirely by that cell in the corner. It's here and it's running. On the left is the main routine. Down to the bottom on the right is a subroutine called bottles that figures out whether to print bottles or bottles depending on the number. If we wanted to understand what's going on in this program, we would stop execution, bring up a wave editor and start editing the code, dragging some breakpoints into various points. Then we start execution up again and run to the first stop point. Once we're there, we can drag cells off of the wave viewer to inspect them, drop them out of viewer there. Now we're doing a map operation on this 321 array to turn it into the text we want. We just finished that and we can see that it changed to 3 bottles, 2 bottles, 1 bottle. Then we look at the playthrough to the end and right before the end we'll go back to the anchor cells so we can see that getting set as the last step. The final program is a Tic Tac Toe AI. The board is over here, some controls here and this is most of the code, well a bunch of code. While this is running you can see some more stacks down here. These are the reverse execution stacks. Every operation has an inverse that's pushed onto that stack and you can play the code backwards in many cases. You can also see that it's going faster than this stack because each higher order function is causing many lower order functions to get executed. Now the core of this algorithm is a list of 8 lines, the 3 horizontal, 3 vertical, 2 diagonal lines through the board, and 2 sets of before and after rules that win or blot on a row. Any language that you implement a Tic Tac Toe AI in would probably have the same sort of 8 line array. What's different about 3rd is that the array was constructed by direct manipulation. By dragging the cells directly from the board onto the list being constructed to set the relationship between the list and the cell locations of the board. Future directions I'd like to take this, I'd like to continue to improve UI, it needs a lot of work. But keep in focus on direct manipulation, it's basically pen based as much as possible. The current of limitations in Tipple is concurrent but it's not parallel, so I'd like to do a multi-processing of limitations. So the next version I'm working in, an interpreter in Erlang, a browser based UI in JavaScript, or whatever you decide to use it, do it, and a restful interface in between the two, the small rest server in the existing code that Staple is developing. But the distant future, my initial motivation in making a reflective visual programming language was, I thought it would be an interesting language due to genetic programming and other evolutionary techniques. I'm particularly interested in programs that are written partially by hand and partially filled in by some machine learning approach like genetic programming or evolutionary programming. So building on the work currently being done in error detection and correction and spreadsheets, my loose guy ideal for this is that a program would normally go along specifying positive and negative test cases at various points of the code and then for some pure portions of the code would say, mark this as to be evolved rather than I'm going to write it by hand. I'd particularly like to see if programs like the tic-tac-toe AI, if you start them out with the line representation written by hand and let them follow the rest of the code, that would be an efficient way to do evolution in programming. Again, the paper is online, this is the website for the third and it's just in time. If you have any questions, thank you very much.