22 March 2007. The new version of the type system is compiled and tested today. This is about 12 days after I started the revision. The next problem, causing a core dump today, is that range types get frozen but are left unresolved at the end of MatchFunction, so we can’t be sure about coercions and run-time types at that point; we have to defer those until we descend again, during code generation. So there is some re-thinking and rewriting to do there.

23 March 2007. Sorting out the relationship between coercions and subtype tests. This has led to a realization that subtypes have to be tested twice: once when manifesting, without asking for coercions because they are unavailable in the presence of range types, and once during code generation after range types have all been resolved, at which point an error could occur. Also privatised expr_rec further, hiding it from its own subtypes.

28 March 2007. Finally finished working on the relationship between coercions and subtype tests. There were two problems: when the upper constraint is a meet type, and when the lower constraint is a variable. Solutions to both have now been documented, implemented and tested. The next step is to insert subtype calls, and the resulting coercions, during code generation.

As you can see, it’s a pretty high-level summary of the coding concerns for that day. This log runs from 2002 to 2008, and documents the progress of the project. Since, I’ve now moved to WebKit in my Information Flow project, I’ve also started keeping a similar log. Recording each minor milestone of implementation work. I’m expecting this log to help me write my thesis, as it will give me remembrance of details that I might otherwise forget.

I’ve also experienced a secondary benefit from keeping this log. The desire to grow the log, compels me to make progress in my work. I’m motivated to do tasks, just so I can mark them as done in the log. Additionally, since the log is geared toward recording smaller changes, I can break big todo’s up into a series of loggable items. I no longer get flummoxed by thinking of the sum total of work that might go into the implementation. Instead, I’m motivated by smaller tasks, which are easily accomplished.

Finally, the very act of documenting the work, and putting my thoughts into words, has helped to concretize my ideas and concerns. Instead of worrying abstractly about nebulous feelings, I now have mold them into precise explanations. Doing this helps me to realize which aspects are ignorable, and what specific actions I can take to answer the open questions.

Finally, I have a technique that allows me to make steady, targeted progress.

First, It doesn’t actually show as much as you think it might. There is a very strong filter on failed languages. By using this test the author runs the risk of re-designing the language, specifically to insert constructs that help them build the compiler. Now, this isn’t necessarily a bad thing, except that compiler writing is now a fairly mature field. There are standard abstractions (esp. in the lexing and parsing) that a new language will probably not experiment with. So, the author will usually just build these existing and well-understood abstractions into the new language. Rather than encouraging language experimentation we get more of the same, but with different syntax.

Second, Not all useful languages even have their own compiler. I’m specifically thinking of the domain specific languages (DSL). Nobody would write an awk interpreter in awk; or a mail engine using sendmail (even if it is Turing Complete). These are languages designed to do a specific task, many of them are quite essential to their respective fields, but none of them are self-hosting. Nor should we expect them to be.

My argument here is that the cultural practice of writing a self-hosting compiler is a big distraction. New languages should be for experimenting with new linguistic constructs. We should be looking toward the DSLs, and incorporating their innovations into our more main-stream languages. Right now, we seem to be optimizing our languages for compiler construction.

I’d rather see our languages evolve in a different direction. I’m really eager to witness the birth of an AI. For this to happen though, we need languages for expressing patterns of thought, not patterns of bits. We need the ability to cohesively and flexibly assemble the stuff of thought. I’m thinking Society of Mind stuff here. We need languages that allow for statistical fuzziness, sloppy associativity, and the ability to construct metaphor.

The linguistic tools that we find useful for building compilers are not necessarily the same tools that will help us build a mind.

Since this marks my first attempt at a paper, and I think the results came out rather weak, I’ll make some brief comments about the process. Because it was a class paper, I spent substantial space and time condensing the other papers on the topic. Studies on the topic are quite sparse, there were really only four such papers, all published later than 2000. So about half of my paper is devoted to repeating their models and observations, followed by an all-too-brief comparative analysis.

The next section introduces some arguments about why the decentralized approach might be doomed to failure. I actually set out with the complete opposite goal, I wanted to find a solution to the problem. But, after many shot-in-the-dark attempts at finding one, I went after an impossibility proof instead. It isn’t what I would really call a rigorous proof though, it’s much more intuitive and informal. But I hadn’t seen the argument made in any other papers, so if I claim a small contribution to the field, this would have to be it.

I actually did follow up the proof, with a section on the methodology for my simulation. I think I was much more detailed about the setup than any of the other researchers were about theirs. I tried, and failed, to repeat the observations of others; so I can’t claim any guarantees about the accuracy of my model and simulation. I tested several off-the-cuff first-shot attempts at what protocols might help alleviate or stall a cascade, with spectacularly poor results. Every protocol I tried was worse than doing nothing! In fact, far worse than doing nothing! Worse by a factor of 50–200! So after all that work, I just figured out some stuff that doesn’t solve the problem, and had to explain why.

I think the best part, though, is the suggestions for Future Work. I’ll probably always enjoy writing this part, because it’s nearly impossible for me to get through my work without thinking of other ways to do stuff, or more things to try out.

Basically, it takes forever to write a paper. And as far as the sciences go, the paper really is really only the tip of the iceberg in terms of effort. It summarizes and represents a substantial amount of effort in data, simulation, code, research, analysis, etc…

My specific gripes about what could be made easier:
• LaTeX gives pretty results, and is the de-facto standard for scientific publication, but it’s kludgy, hard to use, and has a high learning curve.
• There’s no decent and easy graphing/charting programs. So, it’s best to invest time into learning one. I had to write python scripts to parse and reduce my data anyway, so I used matplotlib.
• And there’s no such thing as a vector drawing package that beats drawing sketches on napkins. So conventional artists have nothing to fear. It took hours to find, learn to use, and finally produce, a silly little, nearly superfluous, 7-node graph.
• Network/Graph visualization tools are also scarce, so I had to write my own, just to double check that the simulation behaved properly. I didn’t mention any of this kind of effort in the paper though.

Anyway, go ahead and have a look at my paper: Cascade Failure in Distributed Networks

So, I want to introduce a few constraints and assumptions before I state my rough solution. Assuming the network can be viewed as a graph with nodes and edges, where some goods (power, packets, traffic) is flowing along edges from one node to another, I’d prefer a solution that used local knowledge (node capacity, and possible neighbor capacities) instead of global knowledge. So I’ll assume that each node can keep track of how much stuff is flowing through it, and what the traffic patterns actually are; that is: how much stuff goes from edge 1 to edge 2.

In computer networks it is also possible for a node to track the possible re-routings that certain packets can take and still arrive at their destination. (I don’t know wether this is true of power delivery in the electric grid, but I’m going to assume that something analogous still holds.) Each node will be responsible for measuring traffic capacity: That is for each stream of traffic, it will keep track of what other edges could have had that traffic routed onto them. Each node will also observe a capacity constraint: It will discourage traffic that cannot be re-routed if the primary edge for that traffic suddenly fails. In this way we can keep a reserve capacity in case of edge failure.

When an edge fails, the node will re-route its current traffic in a load balanced manner along the secondary edges available for that traffic. This will temporarily violate the reserve capacity constraint, but not over-traffic other nodes. [Actually I don't think this is true, unless the node can use capacity info from its neighbors] In this way, outage of a single edge cannot trigger a cascade failure, because enough reserve capacity is always available for the traffic that was allocated to the failed edge.

Still to be addressed:
• Node failures which can cause multiple simultaneous edge failures.
• Characterize the efficiency in terms of what is kept as reserve capacity and theoretical max capacity in the naive systems
• Formalize the measurements taken by each node
• Investigate push vs pull flows (power grid is demand based, computer networks are push)
• Do nodes still need a means of capping their flow? (can the power grid drop packets?) I’d prefer not to require this.
• Specify what each node is to communicate to its neighbors
• Investigate the use of probability for multiple node failures (earthquake, software bug). Failures are not generally identically distributed or independent