[cap-talk] definition of the term "safe language"

Sandro Magi naasking at higherlogics.com
Sat Apr 10 09:33:11 PDT 2010


On 09/04/2010 10:43 AM, David Wagner wrote:
> So you're suggesting that as long as long as the language has one
> abstraction that is respected, no matter how minimal, it can be a
> "safe language" even if everything else is just x86/C/etc.?

No, I'd invert that:  if even a single abstraction provided by the
language is violable, it is unsafe as defined by Peirce. It may be safe
in some respects, ie. memory safe, but not in others as Jonathan has
pointed out, re:divide by zero.

> I skeptical that this attempt to define a "safe language" is very
> fruitful.  I think, at most, languages are probably safe in certain
> respects and not in others.

Absolutely. I ended up summarizing the long reply I was composing to
this in a reply yesterday. It really comes down to this:

  Defining a safe language thus consists of defining inviolable
  abstractions via which all program behaviour is expressed. [...]
  a safe language cannot have undefined behaviour.

(where "abstraction violation" is understood to mean "undefined behaviour")

For instance, one can have implicit coercions between abstractions, even
coercions from data to pointers, as long as the language ensures any
invalid or dead pointers cannot be used. This approach is the basis of
some safe region-based memory management type systems.

C is unsafe because, while it provides abstractions like arrays, locals,
structs, etc. virtually none of them are protected. C is pretty much
just syntactic sugar for a byte array language.

Sandro



More information about the cap-talk mailing list