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

[Rob Meijer]

On Wed, September 23, 2009 18:19, David Barbour wrote:
> 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.)

Ok, one useful construct I use often in C++ is operator overloading of
operator()(..) for the creation of C++ function objects that I use to do
capability 'style' programming, but without C++ even being memory safe,
the security implications of this are relatively low (it helps a lot with
human code reviews). Secure languages all don't seem to support equivalent
of operator()(...) overloading, while I feel this construct would make for
a the most convenient way of making capability stil programming in secure
languages simple. Are there any reasons why supporting overloading for ()
and security properties guaranteed by memory safe and/or capability secure
languages could not coexist?

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

I have seen major problem arising from non deterministic ordering of
implicit and deferred destruction. Maybe explicit GC is not what is needed
to solve it, implicit and deferred destruction can be the source of nasty
problems. Possibly what is needed is non deferred implicit GC? If so, how
do memory safe languages do in that area?

Rob