[cap-talk] Specs for our 'ideal' language?

[David Barbour]

Cap-Talk is totally not the place to start another argument about
'ideal' programming languages and feature-sets. But, insofar as you do
discuss features, it's worth discussing how to achieve them in a
capability-secure manner. For example, Ben suggests that "persistence
can be done in a lib", but 'support for persistence' really means
achieving it without violation of other features, such as POLA, and
how well can language persistence be achieved by a lib in a
capability-secure langage? (I'd also note that "persistence" to me
also means persistence of continuations and current activity, not just
of objects.)

I am curious as to what is meant by "proper explicit Garbage
Collection" as stated by Rob Meijer. Do you mean the ability to
destroy capabilities? Or do you refer to some dubious performance
advantage that comes of removing objects explicitly from memory? The
latter is difficult to justify, methinks, but a few annotations
suggesting the compiler attempt to prove that certain memory won't be
used any longer could be nice. I really hate the idea of 'explicit GC'
being accepted as standing above memory safety.

The ability to destroy capabilities is something E does poorly, in my
opinion. Achieving it in E involves providing an interface with a
forwarding reference, and deleting that forwarding reference. I'd want
something that is more amenable to dependency-management, and more
amenable to detecting and repairing partial failures in dependencies.
The approach I've been pursuing to achieve this in my own language is:
* objects may "depend" on other objects, i.e. X depends on Y. This can
be described in certain object configurations.
* if X depends on Y, and Y is lost, then:
** if Y can be regenerated, then X regenerates Y (i.e. using
distributed replicates).
** if Y cannot be regenerated, then X is lost and cannot be regenerated.
* there is a primitive object that can take a command to die and, if
commanded to die, is lost and cannot be regenerated. Attaching
dependencies to such an object is the basis for cascading destruction
of large object configurations.

Advantages of the above design: a 'big hole' is made by cascading
deletes. This hole is easy to detect, and any functionality gap can
thus be detected and recovered by other mechanisms - i.e. asking a
factory-object to create a new object configuration and re-establish
dependencies to replace those that were lost. Support for regeneration
is amenable to heuristic failure in distributed Garbage Collection,
and node loss. This approach allows composition of dependency graphs -
i.e. my stuff can depend on yours. This is much more amenable to
immutable objects than E's design, which allows for cheaper
replication. And it ensures 'explicit' destruction is capability
secure, as it should be.

Other features I'd want:
* Distributed transactions to support composition of services in the
face of concurrency. Being cap-secure for transactions means that no
transaction manager can be permitted to learn which resources were
used unless they know of those resources already. Use of hierarchical
transactions is largely cap-safe, with each object or vat forwarding
'prepare/abort/commit' requests.

* Support for context-objects. This could be used to distribute
certain error-handling policy, process accounting information,
indicate which 'console' to use for error reports, etc. It can also be
used as a vector for certain offline capabilities. The new C++
possesses thread-local variables for similar purpose. In a
capability-secure language, thread-local variables should be avoided,
but having a 'context object' - basically an extra message passed
around between objects and forwarded implicitly through procedure
calls except when explicitly manipulated - can serve just as well or
even better. This is also a powerful basis for dynamically adding
features to the language.

* Support for sealers/unsealer pairs. E language has these. They can
be a basis for many things: rights escalation, SPKI-style
capabilities, static "phantom" typing suitable to dataflow analysis
(since only the unsealer can make use of something sealed by a
sealer). And when a sealed value doesn't cross hosts, it doesn't even
need to be encrypted.

* FirstClass 'plumbing'. I.e the ability to describe event-flows and
functional-reactive subprograms without side-effects and without
relying on 'objects'. This would allow much greater optimization
(shared computations, multi-cast, demand-driven), and can still be
achieved in a capability-safe manner (i.e. the 'sources' for event
streams and functional-reactive data can be caps).

I could go on. There are many, many features I want, and there is much
more detail available on those named above (since I'm implementing
them). But, as noted, this isn't the place for it, except insofar as
the security aspects can be addressed.


On Wed, Sep 23, 2009 at 4:32 AM, Ben Kloosterman <bklooste at gmail.com> wrote:
> C# has a lot of this but it needs some POLA friendly libs ( as do most
> languages) .
>
> * Support for persistence.
>
> That can be done in a lib , WF is an entire lib dedicated to running and
> managing long lived objects you can even store them in SQL so you get cross
> machine persistence. Seems strange to do it in the language.
>
> * POLA confined emakers.
>
> You can use a using block for this though not as elegant , this is how
> resources like SqlConnections are managed. However the IO libs are not POLA
> friendly but this has little to do with the language.
>
>>>From C(++):
>>  * Operator overloading for operator()(...)
>>, function objects
>>    as cap (like) thingies.
>>  * Proper generics.
>>  * Decent performance
>>  * Low level interfacing with FUSE/AppArmor/SeLinux
>>  * Proper explicit garbage collection.
>
> It has all of these  operators , delegates (including anonymous)  , generics
> , performance and pinvokes except the explicit GC , the explicit garbage
> collection is a library thing in Cosmos I have some code that calls free
> with the reference which talks to the GC to collect it. The CLR doesn't have
> it but if you were adding Mono to an OS it would be trivial to add.
>
>>>From Javascript:
>>  * Prototype style inheritance.
>
> C# doesn't have this this the closest is clone and getType or Generics. .
>
>>>From many:
>>  * Memory safety
>>  *  Proper implicit garbage collection.
>
> Got these.
>
> Regards,
>
> Ben
>
>
>
>
>>-----Original Message-----
>>From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
>>bounces at mail.eros-os.org] On Behalf Of Rob Meijer
>>Sent: Wednesday, September 23, 2009 6:14 PM
>>To: General discussions concerning capability systems.
>>Subject: [cap-talk] Specs for our 'ideal' language?
>>
>>With the discussion on C and other languages, I came to think about what
>>my 'ideal' language would look like. Possibly someone here knows a
>>language that comes close, if so I'll immediately will start learning it
>>;-)
>>It would also be interesting to hear from others here how from what
>>existing languages do right, you would describe your ideal language.
>>
>>For me the ideal language would need to look as follows:
>>
>>>From E:
>>  * Support for persistence.
>>  * POLA confined emakers.
>>>From C(++):
>>  * Operator overloading for operator()(...), function objects
>>    as cap (like) thingies.
>>  * Proper generics.
>>  * Decent performance
>>  * Low level interfacing with FUSE/AppArmor/SeLinux
>>  * Proper explicit garbage collection.
>>>From Javascript:
>>  * Prototype style inheritance.
>>>From many:
>>  * Memory safety
>>  *  Proper implicit garbage collection.
>>
>>Hmm, seems like C++ with 50% of the points is still closest to my ideal
>>language, while at the same time being miles and miles from it. Merging
>>C++ and E specs would pretty much do most of the trick though :-)
>>
>>
>>
>>_______________________________________________
>>cap-talk mailing list
>>cap-talk at mail.eros-os.org
>>http://www.eros-os.org/mailman/listinfo/cap-talk
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>