David Hopwood writes: > It's supposed to be the "Programmation fonctionelle sécurisée" > (Secure functional programming), I think. However, I would dispute > that the presence of Names (a.k.a. Tokens) is what distinguishes > capability-secure languages from other languages.
I agree - "names" are not the distinguishing feature. What they do allow is to improve the data-abstraction-building abilities of a language: they allow building abstract data types. The latest diagram is corrected to say "programmation fonctionnelle encapsulée". > In fact it's not features that distinguish object-capability languages; > it's lack of certain misfeatures. Also, all of the other distinguishing > properties shown on the diagram (state, unification, constraints, > nondeterministic choice, ports, streams, call by need, transactions, etc.) > are orthogonal to whether a language is capability-secure -- so it would > be more accurate just to say that every box has a capability-secure variant. I would mostly agree with this. There are some features that are more critical than others, though. For example, global shared state is definitely a bad default for a capability-secure language, while local state is ok. For global communication in a capability-secure language, message passing between independent entities seems to be the right default. Concurrency is a necessary requirement for a capability-secure language, but it has to be done right so that it doesn't open covert channels. In E, for example, each vat is actually a sequential process and concurrency is deterministic. Between vats there is nondeterministic concurrency. I would say that "object capabilities", the special form of capability that E and some other languages have, seem to be a good concept for secure programs. So the box for "object-capability programming" that is in the new diagram, for the concepts closure + port + thread + local state, seems to be reasonable. This doesn't mean that other good capability-secure islands don't exist elsewhere in the diagram. As you say, there are many capability-secure variants! But the arguments for the other boxes are not (yet) compelling enough to make them "principal" programming paradigms, in my view. Peter _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
