[e-lang] E research topics

[Mark S. Miller]

Stephan van Staden wrote:
> I'm planning to do a PhD over the following three years. I've read 
> MarkM's PhD dissertation and am interested in research topics involving 
> E. My primary interests are
> 
>     * Programming languages
>     * Compilers, interpreters & virtual machines
>     * Distributed systems
>     * Networks & security
>     * Operating systems
>     * Mathematical stuff
> 
> Of course, my interests are not limited to these areas (e.g. my MSc 
> dissertation involved data mining). If you have any future research 
> requests or ideas involving E, please state them.


Hi Stephan, glad to hear about your interests!

First, I'd like to say that all the suggestions so far sound good. You could 
also do a great service to the e-lang community by gathering the research 
topics you find interesting, whether for you or someone else to pursue, and 
adding pages to our wiki explaining each. This strikes me as an ideal use for 
a wiki: a possibly interesting idea might gather a diversity of elaborations 
until it becomes a compelling research topic.

In any case, here are some pointers to additional possible research topics you 
might consider. In each case, the work we've done so far, IMO, barely 
scratches the surface. I believe each needs to be elaborated into a 
substantial investigation. I will postpone further elaborations until we get 
some reactions.


* Auditing <http://www.erights.org/elang/kernel/auditors/>. Note that the 
E-on-CL auditing system is quite different from the one documented here, with 
interesting advantages and disadvantages. The current E-on-Java is slowly 
working towards yet another take on an auditing architecture, but it's much 
less far along. Joe-E special cases some built-in auditors, but we've talked 
about generalizing it to an openly extensible static auditing framework.

During the Waterken security review, we found that around 25% of the classes 
in the Waterken system were Powerless. In other words, they had passed the 
Joe-E static checker assuring that they were authority-free. As a result, we 
were able to ignore these regarding many security-relevant questions during 
the review. This demonstrates that the auditing idea has a lot of value.


* Safe Serialization Under Mutual Suspicion 
<http://erights.org/data/serial/jhu-paper/>. AFAIK, the issues involved in 
serializing a graph of mutually suspicious objects is otherwise unexplored. At 
these pages, I think we raise more questions than we answer. The need for a 
good serialization framework meeting these goals seems to come up over and 
over again in different contexts. The notion (due to Jonathan Rees) of 
serialization as un-evaluations seems like a very rich starting point.

In a recent conversation with Alan Karp and Marc Stiegler, we arrived at a new 
perspective on un-evaluation. At one simple extreme, we have the literal 
realism of orthogonal persistence, where objects simply get to keep whatever 
rights they acquired. We assume that a held permission can only be acquired 
"legitimately", so the holding of a permission is an adequate demonstration of 
a the right to continue holding that permission.

At a hypothetical simple opposite extreme approximated by SPKI, the entire 
delegation chain by which a permission was actually acquired is recorded, and 
is presented afresh each time the permission is exercised, effectively as a 
chain of title (sharings, not transfers), enabling a fresh check each time 
that the permission was acquired legitimately. When these two give extremes 
always give the same answer, the difference is uninteresting. However, if the 
"rules" change, the first "historyless" system can only grandfather-in all 
permissions acquired so far by the old rules. OTOH, the SPKI-like system can 
determine whether to accept as legitimate, under the new rules, the means by 
which the permissions were acquired under the old. (Note: in general, and 
especially in the human world, I generally prefer historyless rights systems 
over retro-active re-evaluations. But both have a place.)

Un-evaluation is a complex expressive mid-point between these two. In order 
for the object to retain its rights across a serialization boundary, i.e., to 
reconstitute an object like itself with permissions like those it currently 
holds, it must be able to construct from its current state a rationalization 
(the uncall), i.e., a simplified story about how it could have gotten these 
permissions. In the world in which this expression is evaluated, it may or may 
not succeed at re-obtaining permissions like those it held.


* Quasi-literals <http://erights.org/elang/grammar/quasi-overview.html>. See 
especially the end of that page for some possible directions.


* Trying to adapt E-like concurrency control models for making use of 
multi-core systems. I think the re-introduction of the Joule multi-channel 
into E will help us to introduce data parallelism into E.


* David Hopwood is working towards an exception-handling-as-backtracking 
proposal for E.


* I hope that the "programming as plan coordination" perspective is itself 
thought provoking. I do think most bugs can be understood in terms of plan 
interference due to assumption mismatch. It would be wonderful to find a way 
to investigate these topics.


* Part IV of my thesis on Emergent Robustness suggests a framework -- the 
fractal access matrix as attack surface -- with which one could make 
quantifiable arguments about relative robustness. A paper recently mentioned 
on LtU, The Structure and Value of Modularity in Software Design 
<http://lambda-the-ultimate.org/node/2190> suggests an economic framework, 
using options valuation, for making quantifiable arguments about relative 
modularity of different architectures. Do these frameworks have a similar 
underlying structure? Is there a unified way of looking at both issues? How 
might one measure or empirically investigate any of this?


* A soft/gradual/hybrid type system for E, or for an E-like language.


* Agorics and Smart Contracting, of course. These topics remain wide open. The 
global economy is held together by a fabric of contracts, all of which 
currently are interpreted only by humans. I think, in the long run, Smart 
Contracting is what will be seen as really important about our work. The 
access control, concurrency control, protocols, and object language 
foundations we're currently spending so much time on will only be remembered 
as a stepping stone for getting there.


-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM