kosik at fiit.stuba.sk
Sat Mar 13 00:47:45 PST 2010
Kenton Varda wrote:
> On Wed, Mar 10, 2010 at 3:55 AM, Matej Kosik <kosik at fiit.stuba.sk
> <mailto:kosik at fiit.stuba.sk>> wrote:
> Kenton Varda wrote:
> > What do you think? Please tell me your ideas for how we can use this.
> I think, the term "object-capability language" makes sense and I do not
> regard it as a mere hyponym of the term "object-oriented language".
> For non-object-oriented languages (c.f.
> From the ocaml web site <http://caml.inria.fr/ocaml/index.en.html>:
> "Objective Caml is the most popular variant of the Caml language. From a
> language standpoint, it extends the core Caml language *with a
> fully-fledged object-oriented layer*, as well as a powerful module
> system, all connected by a sound, polymorphic type system featuring type
> So OCaml and Emily are OO languages. Can you name an ocap language that
> is not OO?
I insist on this example because the fact that OCaml also supports OO is
a mere coincidence. Those features were irrelevant during taming
process. If you yanked OO features out of the language it would be even
easier to turn it into object-capability language because there would be
less stuff you had to review.
More examples could be provided but this single one is sufficient.
To confuse you more, in case of Ocaml, rather than talking about
"object-capabilities" we could talk about "function-capabilities" or
"procedure-capabilities". These have the same properties as described by
Mark Miller in his thesis in Section 9.2. Those who have a capability to
a function (or a procedure) have the permission to call designated
function (or procedure). Connectivity by:
- initial conditiosn
makes perfect sense even though capabilities designate functions (or
procedures) instead of OO objects.
More information about the cap-talk