[cap-talk] designing new language.

[David Barbour]

Something I've found very useful in my designs is good language support for
revocation membranes (i.e. applies to not just the object, but also every
object received or returned by it).

If you're pursuing distributed computation, you might want to support unum
patterns. Also, declarative expression of distribution in terms of
capabilities (A nearby B) worked well for me, as does simple temporal
semantics (message arrives in so many *logical* milliseconds) as a secure
basis of concurrency control (i.e. where transactions, mutexes, promises,
etc. tend to be subject to denial-of-service attacks).

Effective control over resource costs (time, space) is useful, to
additionally protect against denial-of-service attacks. This can be achieved
through capabilities (e.g. to allocators and schedulers) but however you
achieve it will heavily impact language design.

Simple failure modes are valuable. One design I developed perhaps four years
ago is to declaratively state dependencies (A depends on B), such that when
B is disabled (or unavailable), A is also disabled (or unavailable). I
combined this with 'suicide' objects that accepted a 'die()' command. This
is valuable because failures would cascade out to predictable boundaries,
where they are easy to detect and recover from, as opposed to limping along.
It also serves as a capability-secure replacement for 'free' - which is
useful since distributed GC should be avoided if feasible.

Support for ephemerons ('weak refs' with identity) can be useful in
developing frameworks and certain abstractions in a traditional object
capability model. I pursued them for a while. I caution, though, that using
shallow identity for objects has plenty of semantic and optimization
problems. A variation based on a path ADT might be a better option. I don't
use ephemerons in my current design.

How you integrate FFI and manage security policy is an interesting subject
with respect to both capabilities and una, and can have a pretty deep impact
on language design and implementation. For example, I ended up developing a
plugin-extensible language runtime to support a variety of 'high level' FFIs
- in part because it is much easier to decide appropriate security policy
for high-level concepts. (E.g. local storage vs. filesystem access. Even
things like HTTP access can be divided by lines like 'LAN HTTP' (192.168,
127, 10.0.0) vs. 'GLOBAL HTTP'.)




On Fri, Aug 12, 2011 at 11:09 AM, David Nicol <davidnicol at gmail.com> wrote:

>
> I find myself designing a new programming language.
>
> Looking from a capabilities perspective, what is The Big Wishlist, with
> proper terminology?
>
> I think I've got it already --   "newcap = delegate(cap)" and so on but is
> anyone willing to
> discuss design notes off-list under a temporary NDA? Deferred compensation
> available.
>
> --
> "The tools expect that they have full, unlimited control of the hardware."
>  -- Intel Corporation
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20110812/73105a0d/attachment.html