Ill Communication

So last night I was doing a bit of thinking about how to write my own mud client. I love muds and always have. I think they're incredibly fun, despite not having any real graphics.

In any case, I started thinking about "what is the algebraic structure of communication?". In other words, if we have a server and its clients what is the proper mathematical structure that represents this communication. I guess this is connected to pi-calculus, but I'm not sure if that's exactly what I want. Ideally I want some category theoretic structure that can describe the evolution and interactions of such a system.

Inherent Flaws

Even though I haven't spent as much time as I would have liked thinking about it, I have a feeling that my ideas on trying to connect arrows and resumptions just really aren't going anywhere special. Part of the problem is that resumptions inherently signify breaking points within the process. Now, I had been somewhat naively thinking that the connections between arrows could provide these breaking points as well but that doesn't really work. Arrows are connected with combinators, and once connected there is no way to break them apart again. In general, there can be more than one set of functions that can be composed to make a given function.For example, there's obviously an infinite number of pairs of functions over the integers that can be composed to give (\x -> x+4).

Of course, that does make me wonder what a category would look like if every morphism that was composed of two other morphisms had a unique decomposition.

Resumptions & Arrows

So I've been doing a bit of reading of the paper Cheap (But Functional) Threads and I can't help but wonder how this paper and its Resumption monads might connect to Functional Reactive Programming. Essentially, the mapping I see is that a graph of arrows should corresond to the set of resumptions in the system. My brain is still very fuzzy on this point, so I need to write up some notes making the correspondence truly explicit. I'm not sure what good this correspondence might give, but I'm willing to bet good money that recasting this paper in terms of arrows might actually give greater power.

Capabilities in Pure Functional Operating Systems

This is the topic to which I have been putting all my, albeit limited, brain power.
Capabilities are a very elegant way to handle security, where every resource corresponds to some key that denotes access rights and the keys are passed to and between user processes.
In some older systems, capabilities are essentially just pointers with some extra information attached to them. That model doesn't really fit well into the natural style of functional programming so instead we'll be using static capabilities as outlined in this paper.

As much as I find the Lightweight Static Capabilities paper inspiring, one problem it doesn't tackle is revocation. To push the analogy further, one must be able to change the locks after one has given out the keys. My group's tenative solution to this is to keep a list of capabilities associated with each process which are to be passed in as parameters in the construction of an action. When a system call occurs, a continuation of the running program is to be stored along with this list of the capabilities passed to it the last time it was started. Revocation will occur when a process that has the proper authority to revoke names the process who is going to lose access and provide the capability that is to be revoked. The kernel will then remove this capability from the list associated with the process and when the process is restarted it will be rebuilt with its modified list of capabilities.

This is of course a very tenative design, with most of our ideas based upon the House system and the related work on the OSker kernel.