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

[David Barbour]

On Wed, Sep 23, 2009 at 11:02 AM, Rob Meijer <capibara at xs4all.nl> wrote:
> Secure languages all don't seem to support equivalent of operator()(...) overloading

I must say, use of the '...' argument in C/C++ hardly makes for
typesafe programming, much less memory-safe.

Pretty much any dynamically typed language provides equivalent to
operator()(...) - the ability to take a list of arbitrary arguments of
arbitrary types and process it. Some, like E, will use a slightly
different name than 'operator()'... i.e. 'run([args])'.

>
> Are there any reasons why supporting overloading for ()
> and security properties guaranteed by memory safe and/or capability secure
> languages could not coexist?

No, none at all. Overloading itself isn't problematic; supporting
lists of arguments of arbitrary types is, however, somewhat
problematic if aiming simultaneously for *static* type-safety and
*modular* secure components, for a similar reason that you can't have
templated virtual methods in C++.

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

I'm supposing that you're talking about release of non-memory
resources, side-effects in object destructors, and that sort of thing.

I suggest that part of what you're seeing is a language smell or
mismatch - i.e. OS resources given poor representation in the
programming environment. A language designed to achieve 'persistence'
is likely to do much better: persistence implies the language must
know how to 'regenerate' access/subscription/etc. to an OS resource
when coming out of hibernation, which in turn implies the language is
free to hibernate access to a resource whenever it isn't immediately
required. You'd also avoid distractions such as opened vs. closed
files; a file-object will be open if appropriate, under-the-hood.

Mutexes and locks are, similarly, a *severe* language smell. They
can't be allowed in a language if it is to support composition with
concurrency.

If you're seeking something similar to the exception-safety of C++
RAII, the use of something similar to D's "scope" keyword is
appropriate - it just executes the scoped commands in reverse order
upon exit from the scope. You shouldn't need to do this often, though,
in a language designed for concurrency and persistence.

Anyhow, side-effects on GC are (IMO) a terrible idea.