[e-lang] Unsafe code in capability languages

[Kevin Reid]

On Aug 29, 2006, at 12:22, Constantine Plotnikov wrote:

> 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.

It would indeed be unnatural, and E does not do this. E does not care  
about files in this way; it is merely that code intended to be  
evaluated in a privileged environment is conventionally called .e  
instead of .emaker, and invoked in different ways.

> I suggest making execution of privileged code more capability-like.

There is no such thing as privileged code, except in that some code  
holds 'privileged' capabilities. They may be passed normally.

> 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);
>             }
>         }
>     }
> }

In actual E, this code would be:

def makeStdout(<unsafe>) :any {
     def stdout := <unsafe:java.lang.System>.getOut()
     return def object {
         to println(text :String) :void {
             stdout.println(text)
         }
     }
}

The unsafe loader, <unsafe> (aka unsafe__uriGetter), is passed as an  
ordinary reference/capability. The product of it is also an ordinary  
reference.

No special "unsafe" construct is needed, and its introduction would  
be unwise; 'unsafety' is inherently relative and the language should  
not have a built-in definition of it.

> 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.

Such operations can be handled by ordinary calls, without special  
language constructs (though possibly with transparent compiler support).

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>