Lambda the Ultimate

Yes, I have implied an efficiency concern with that statement, although I haven't been giving it much thought; as you have mentioned, there are ways of implementating this which are probably sufficiently performant. The main concern I have, however, is how this influences the prototype-instance relationship: because for the methods are explicitly assigned to each new object, the prototype inheritance relationship is lost. That is, if I do the following:

function Counter() {
   var value = 0;

   this.increment = function() {value += 1;};
   this.getValue = function() {return value;}
}

var c = new Counter();

then I cannot change the implementation of all Counter's increment() functions, like so:

Counter.prototype.increment = function() {print ("Incremented!");}
c.increment(); // still the old version

because c has an explicitly set value for bar and thus doesn't query its prototype. For "normal" methods (that is, those only assigned to Counter.prototype) this would work, however. Thus, you need to know beforehand which methods are private member accessing and which not, which is awkward. (I know the example isn't very illustrative, but you probably get the idea.)

Thanks for pointing out serialization, I haven't thought about that. However, I didn't plan for any form of built-in runtime-level serialization mechanisms in my language, so this shouldn't be an issue. Object references are naturally designed to be unforgeable (that is, there is nothing like pointer arithmetic or a global object table).

The model is unfortunately not sufficient to model separate read and write capabilities; the object key is always a capability for both. There are ways around that, like introducing the ability to "freeze" slots make them immutable, or to only pass a key to a new slot which returns the actual slot's value through a method; but I admit that these are not optimal (though maybe sufficient in practice; in any case, the assumed main use of this scheme, which is slots private to a single object - or a group of mutually trusting objects -, does not seem affected by this restriction).

Nice catch.

setSlot( getSlot, \ slot -> "Muhuhahahaha!" )

do you always do a clone of any ocap before passing it to untrusted code?

If you need special protocols to handle 'untrusted code', you certainly don't have an ocap system.

I may have oversimplified a bit by bringing "getSlot" on the table. I guess that for this to work, slot lookup needs to be intrinsic to the system, and this is actually how I planned it for my language. More specifically, a slot of an object can only be accessed by sending that object a message with the key as selector. As in Self, if the slot contains a method object it is executed and its return value is the result of the message send, otherwise the slot's value itself is returned.

So, no "getSlot" overriding madness. ;)

I understand your objections to using the term "object capabilities" in this context. I was actually just referring to the analogy to object capabilities regarding access control through references and unforgeability, but you are right that this makes objects themselves move away to be object capabilities in the pure sense of the word (in that a reference to an object may mean different capabilities in different contexts depending on which keys are available in these contexts).

However, the password analogy you mentioned is a bit misleading, too, as passwords are forgeable - they are inherently based on being "only" hard to guess, while I am explicitly talking about the use of unforgeable keys (I know you actually noticed that, I just wanted to highlight the flawed analogy).

While you're reviewing the literature, also have a look at Web Sandbox. It was influential in establishing the proxy model of capabilities for JavaScript, and while it's still a research project, it is currently in use as an DOM isolation technology for Hotmail.

I haven't seen enough work in bidirectional nor reactive systems to substantiate claims about large, long-lived systems (and I am aware of large, long-lived projects that use them). Furthermore, I don't typically associate bidirectional languages with reflective ones -- they're very constraining in practice, at least today, which isn't fun when working with reflective (and, I assume of interest, introspective) abilities: that's hard code to analyze, so inverting it is a bit of a reach. Likewise, bidirectionality is typically orthogonal to dynamism (they don't mix well, so they're shielded from each other whenever I see a system with both). Overall, I'm confused by your positioning of these ideas.

This isn't a critique of the ideas. They're fascinating -- I used to make reactive languages and am now doing the runtime optimizations for, in part, a bidirectional language.

Most of my dayjob work is in large, long-lived, reactive systems. However, the systems I speak of are architecture-based rather than language-based... e.g. publish/subscribe, blackboards or tuple spaces. These architectures have proven very flexible (and moderately scalable) for integrating and independently developing new components and extensions.

While these architectures are flexible (aka dynamic) 'in-the-large', it turns out they are rather painful to work with 'in-the-small'. The languages we use (C++ and JavaScript, mostly) are simply not well adapted to the architecture. Managing subscriptions and caches are especially painful.

On occasion the 'native' data format (the initial view presented to modules) happens to be the view we need to make good decisions and take actions. In that case, all we need is a simple subscription, or simple updates. Since it simplifies our lives, we try to ensure this is the case as often as possible by intelligently designing (and redesigning) the data model.

But there will always be some user story that needs a different view. A common case I work with is adapting to new protocols. In those cases, a module is forced to gather a bunch of scattered data into a new view, often managing a large number of subscriptions, dropping or adding subscriptions based on changes in the data. Keeping a view 'consistent' with the native model is a non-trivial exercise. Eventually, we make decisions and take action. These cannot just be reflected in the local 'view' we have constructed; our decisions must propagate back to the native model (and then further, to sensors and actuators). Thus, we also maintain the relationship from the view back to its source.

The fundamental requirements seem to be reactivity (to maintain multiple, consistent views in a concurrent system) and bidirectional mapping (so decisions and actions made on a view will propagate to its source). This becomes difficult when a 'view' comes from composing observations from diverse elements in some other model - which is not uncommon. Multiple models and bidirectional influence, together, give us dynamism - the ability to extend the system with new protocols, new data sources, new ideas, new domains and disciplines.

(Modeling everything as data is also useful for highly dynamic, reflective systems. For my dayjob project, the design we came up with added method-calls separate from the data model for reasons of 'efficiency'. We have since come to regret that decision because it hinders extending the system with replay, auditing, and post-mission analysis. Were we to do it over, every method-call would be associated with a fresh data entity.)

You say bidirectional is 'very constraining', but I do not mean to suggest our languages should constrain us such that every function and data-binding must be bidirectional and lossless. I'd be very happy if our languages simply made the bidirectional properties a lot easier to achieve and compose. At the very least, we need to more tightly couple the notions of 'reactive', 'view', and 'control'. It is only natural that, when we see something, we want to reach in and touch it. The problem with most OO data models is that such changes tend to modify the view rather than the cause for the view. My own efforts towards more bidirectional programming are based on the notion of demand-driven systems, e.g. a video camera might power on only because it is being viewed. Parameterized demands can serve both as queries and constraints.

I've read a lot about your work with flapjax. I don't see anything on your perpetual-student page about bidirectional programming. What is it you're working on?

Ah, I misunderstood reactive and bidirectional systems -- which are inherent properties of the program -- with language-based techniques for achieving them. My point was just that we don't know have proof that the language-based approach is the way to go or how for systems of scale; they're awesome, but very much research.

Thibaud Hottelier is designing a bidirectional layout and animation language. As one backend, a synthesizer finds attribute grammars to compute various directions of flow, which feeds into my part, a fast (parallel, SIMD, memory-optimized) AG solver, and a more murky story on the rendering (OpenGL and Qt today, hopefully canvas and OpenVG soon). As a frontend, you can use a lot of the normal syntactic abstraction facilities of the browser -- xml, selectors, cascading -- optimization problems we've done great with already wrt parallelism.

we don't have proof that the language-based approach is the way to go or how for systems of scale; they're awesome, but very much research

I grant this is true. On the other hand, I've seen plenty of evidence that prototype-based OO does not retain 'highly dynamic and reflective' properties at scale. I believe seeking alternative solutions among architectures and experimental language design is quite rational. Taking the well-trodden path of prototype-based OO and expecting different results (without significant changes) is insanity.

Your new project sounds interesting. I'll look into it over the next week.

On prototypes: I used to do a lot actionscript development: there, the ability to manipulate the central MovieClip object was powerful. Unfortunately, the common use of prototypes -- js for the DOM -- crippled the main object of manipulation (dom) and now, while finally more consistent, the security camp (cough capabilities) put the nail in the coffin. I agree about the comments about scale and introspection. The dynamism isn't amazing, but does serve a purpose -- however, as
seen in JS's continuing evolution, the MOP needs to be rich (eg, dynamic accessors).

We haven't written much up recently. There was a rejected paper last year on the constraint language and I have a thesis proposal draft touching part of it; we've made great strides recently and will probably write up a few things this year (css semantics, new parallel algorithms and language implementations, etc.)