[e-lang] How Emily Tamed the CAML

[Brandon Moore]

Brandon Moore wrote:
> Mark Miller wrote:
>   
>> http://www.hpl.hp.com/techreports/2006/HPL-2006-116.html
>>
>> Enjoy!
>>   
>>     
>
> So far, I just have a few comments about formatting. The pdf from
> http://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf
> positions figures a bit unusually:
>
> figures 3 and 6 strand a bit of text at the top of the page. It's 
> especially annoying with figure 3, because the figure is taller, and 
> it's just a tiny bit of text.
>
> Table 1 is split across a page boundary. I don't think the table adds 
> much to the paper anyway, except by providing some examples of the sorts 
> of things considered potentially dangerous ambient authority.
>
> Example 1 is as long as many things that get a page of their own, but I 
> don't quite see how to shuffle the text and other examples around if you 
> did that.
>   
Well, I didn't mean to send these nitpicks to everybody. I guess I'll 
just have to say something more interesting now.

It seems to be that solutions to performance problems around 
intermediation in Emily would yield optimizations that might be applied 
to intermediation in other object-capability languages, if you look 
closely enough at them.

If an interface is a record of functions to being with, copying a subset 
of those functions to another record should supply a restricted 
interface at no additional cost.
Similarly, if intermediation doesn't impose extra costs in E, it's 
because the original object is already suffering from indirection overhead.

Catching up in performance with less-secured O'Caml code entails finding 
ways to implement intermediation without paying for indirection, even if 
that's not obvious at the source level. I guess the cost is probably 
instead the cost of conforming to a type system that can carry out some 
of the security analysis for you. The work from Oleg's paper might come 
in here too.

As for actual suggestions on performance, it should be possible to 
modify modules with no runtime cost using (opaque) functors, as long as 
you want to statically restrict some interface. I think it's also 
possible to assign an object a restricted type that hides formerly 
visible methods without any runtime costs, or even interfering with 
inlining opportunities.

Brandon