[cap-talk] controversial article

Matej Kosik kosik at fiit.stuba.sk
Fri Jul 3 17:22:23 EDT 2009


David-Sarah Hopwood wrote:
> Mark Miller wrote:
>> On Thu, Jul 2, 2009 at 12:17 PM, David Wagner <daw at cs.berkeley.edu> wrote:
>>> Matej Kosik  wrote:
>>>> I hope that it is correct to say that all object-capability programming
>>>> languages can be used for creating software systems that are defensively
>>>> consistent but none of these languages (or platforms) can be used for
>>>> creating defensively correct software systems. (?)
>>> To be pedantic, they can plausibly be used to build defensively
>>> correct software systems (they're Turing-complete, after all); it's
>>> more that those languages don't provide special support for reasoning
>>> about or ensuring defensive correctness.  So those languages don't
>>> provide any extra help; if you want defensive correctness, you're
>>> on your own.
>> To be meta-hyper-turbo-pedantic, I claim this is false.
> 
> Indeed, and note that David's argument is incorrect because these languages
> are *not*, strictly speaking, Turing-complete. A Universal Turing Machine
> would have unlimited memory.
> 

Ok, let us put Turing completeness aside.
(In fact, I would rather talk about "Milner completeness"
 or "Milner incompleteness"---unless system like this:
 http://altair.fiit.stuba.sk/mediawiki/index.php/SandboxedPing
 can be expressed as a Turing machine)

However, the rest of the David Wagner's post will probably help me to
explain better why are those odd concepts (domain, regular send vs.
donating send) I introduced useful.
They simply provide cheaper way for defending against cancer- and
spammer-like threats that performing in-depth analysis of an untrusted
code. Without such analysis we will not reveal whether some of the
subsystem does not behave like "cancer" or like "spammer" but if they
eventually behave that way, we have simple mechanisms how to identify
the perpitrator so that we can kill it and enable progress of unrelated
subsystems (that do not rely on services of the killed server).


More information about the cap-talk mailing list