[e-lang] Unsafe code in capability languages

[Constantine Plotnikov]

I want suggest a minor improvement to way how unsafe code is invoked in 
E (possibly it can be implemented in Emily too). As I understand, 
currently the whether code is considered to be able to invoke unsafe 
operations is determined by in which file it is defined. This looks 
somewhat unnatural for me, and it is somewhat unfriendly to runtime code 
generation and mobile code.

I suggest making execution of privileged code more capability-like. To 
achieve this, I suggest adopting the C# "unsafe" statement with a small 
twist. I believe that my proposal allows eliminating special classes of 
source files from E.

There is an object in E runtime named unsafeKey. The object is stored in 
VM's unsafeKey register. The object is considered to be mutable and thus 
it cannot be assigned to constant.

The object is passed as first argument of main function. The main 
function can pass unsafeKey to services that need to invoke unsafe 
functionality. The classes that need to invoke unsafe functionality do 
it in the following way:

unsafe(<unsafe key>) {
    // operations
}

Unsafe operators are allowed only in lexical scope of unsafe operation. 
The open issue is whether to allow unsafe operations in closures within 
the lexical scope (I'm leaning against it, but possibly it is perfectly 
safe; however analysis is required here). The body is executed only if 
object passed as unsafe key to unsafe statement is identical to value 
stored in unsafe register of virtual machine, otherwise an exception is 
thrown and body is not executed.

Below is a HelloWorld program that demonstrate unsafe statement

# application entry point
def HelloWorld(unsafeKey, args) : any {
    def stdout := makeStdout(unsafeKey)
    stdout.println("Hello, World!")
}

# stdout service
def makeStdout(unsafeKey) : any {
    def stdout := unsafe(unsafeKey) {
        <unsafe:java.lang.System>.getOut()
    }
    return object {
        to println(text:string) {
            unsafe(unsafeKey) {
                # assuming that println is untamed
                stdout.println(text);
            }
        }
    }
}

Generally speaking, the code within unsafe construct is environment 
specific and it can contain constructs specific to execution 
environment. For example native implementation of E might contains 
operations that allocate/free non garbage collected memory and exchange 
data with it.

Constantine