That was (is?) all about capabilities.
1. Your documentation introducing capabilities specifically says: "Pony capabilities are completely new, no other language has them." If you really mean "capability" in Mark Miller's sense of the word, then this statement is incorrect. Many object-capability languages exist.
2. What your documentation describes as "capabilities" looks to me like type qualifiers. The documentation says "A capability is a form of type qualifier and provides a lot more guarantees than const does!" But this doesn't sound anything like capabilities.
Is it possible that Pony is an object-capability language but you are also using the word to refer to a different concept? If Pony is actually an object-cap language then that's excellent, and I even more so encourage you to rename the type qualifier concept to avoid the confusion!
FWIW, Sandstorm is very interested in adopting a high-performance ocap language, but would probably shy away from one which uses the word "capbaility" to mean something else, for fear of confusing developers.
Sorry for the docs misunderstanding - I promise, bad docs not withstanding, we are using "capability" to mean exactly what you want us to mean :)
We use capabilities in Pony to statically avoid data races - not for security. But we believe that Pony's capabilities can also be developed further to support security - would be great to try and program Sandstorm’s security with them.
Right, capability-based security (my definition) originated in the 60s and has been in continual use ever since. Pony's definition is new, AFAIK (and according to the documentation).
> We would have loved to use a different word, but there are not enough different recognisable words in the English language.
I think "type qualifiers" is the correct term. The Pony docs already describe capabilities as being similar to C++'s "const" and "volatile" type qualifiers, and this term will help people understand that the concept is similar (but more advanced).
The Pony docs spend a whole paragraph explaining that its capabilities are not the same thing as any other "capabilities" I may have heard of, e.g. "You may have heard of capabilities somewhere else, but these are not the same thing." The fact that you need this paragraph suggests that you've heard this objection a number of times, which should be demonstration enough that you really ought to choose a different term. People don't usually need disclaimers like this. English is a language that has entirely too many words -- there are plenty available. Or, consider making one up. :)
> But we believe that Pony's capabilities can also be developed further to support security
Yes, it's very likely that your "capabilities" would compose well with object capabilities in order to effect security. But that's just all the more reason they shouldn't use the same word, since it will be incredibly confusing to anyone who is trying to use both.
You may be interested in the type system paper that covers this:
http://tutorial.ponylang.org/capabilities/introduction/
It seems to state that the type qualifiers are the capabilities, and explicitly claims no existing language support capabilities.
If this is just an issue of misleading documentation then I apologize for raising a false alarm, though the documentation should be corrected. :)
No worries on a false alarm, as I am always eager to discuss capabilities security, in any form :)
If Pony were using "capability" to describe the combination of a variable and its qualifiers, then I'd say, yes, that's a capability -- it designates a thing, and the permission to use it. But they are using "capability" to describe specifically the _qualifiers_ on the variable, which is not correct, and is confusing.
Here's a great paper discussing what capabilities are and the confusion around them: http://zesty.ca/capmyths/usenix.pdf
Before you ask: Yes, Linux/POSIX capabilities (as described on the capabilities(7) man page) are similarly misnamed. This is covered in the paper, and has been a source of a lot of confusion.
1960s-1970s: Capability-based security invented, popularized, widely used, almost makes it into hardware (Intel 432).
1980s-1990s: People incorrectly redefine capabilities in various ways (e.g. as verbs rather than nouns), then declare "capability-based security doesn't work" based on these misunderstandings (see the paper I linked). Capability systems find they have trouble making headway against these misconceptions, as the difference between the misconceived version and what capabilities really are are just subtle enough to confuse anyone who isn't immersed in it. (Meanwhile, the basic ideas of capabilities live on as object-oriented programming, but aren't enforced strictly enough to be called "security".)
2000s-2010s: People start realizing that capabilities as originally defined do in fact work ridiculously well and they become re-accepted.
We really don't want to go backwards again. :/
Unfortunately, it turns out they have simply coopted the term to mean something completely different. According to the documentation: "Pony capabilities are completely new, no other language has them."[0]
Please think of a new word for this; don't redefine one (or a pair) that is widely-used already.
[0] http://tutorial.ponylang.org/capabilities/introduction/