Lambda the Ultimate

From Matt Blaze's Shaking Down Science blog post, a letter from the U.Penn. library to faculty:

I am writing to bring to your attention a recent change in IEEE's policy for archiving personal papers within institutional repositories. IEEE altered their policy in January from allowing published versions of articles to be saved in repositories, like ScholarlyCommons, to only allowing pre-published versions. We received no prior notice about this change.

As a result, if you or your students/colleagues publish with IEEE and submit papers to ScholarlyCommons, I am writing to ask that you PLEASE REFRAIN FROM UPLOADING ANY NEW PUBLISHED VERSIONS OF ARTICLES. It is unclear yet whether IEEE material uploaded prior to January already within ScholarlyCommons will need to be removed. Anything new added at this point, however, would be in violation of their new policy.

I.e., the IEEE journals go from being green (allow authors to distribute as-published versions) to pale green (author's may only distribute preprints).

Hello LtU community,

As this is my first post here in LtU, I'll briefly introduce myself. My name is Denis Washingotn, and I am an end-of-first-semester CS student at the Humboldt University Berlin, Germany. I am very interested in programming language theory and did much personal research on it in the last few years, including writing an LLVM-based compiler for a safe statically compiled C-like language in C++ as a hobby project. (I actually planned to release that as open source and had already implemented several control structures, boolean and number types, arrays and first-class functions, but lost interest because after more and more research because I increasingly found the language to be too "baroque" and unexciting.)

Nowadays, my interest lies primarily in highly dynamic, reflective object-oriented languages; in fact, I am in the process of trying to design a prototype-based language vaguely in the vain of Self, NewtonScript and Io, with a special emphasis on conceptual simplicity and reflective capabilities a'la Smalltalk while trying to maintain a reasonable level of approachability for users of established mainstream scripting languages (like Python, Ruby, PHP, etc.).

In relation to this, I have been investigating the possibility of effective encapsulation of state for highly modifiable slot-based objects as found in several object-centered languages. Regarding this I found a paper on the encapsulation mechanism of Self prior to version 3 (Parents are Shared Parts: Inheritance and Encapsulation in Self) where slots could be declared as "private"; such slots can then only be referred to by objects of the same delegation family. (However, according to the comments on the selflanguage.org discussion forum, the privacy declarations have been degraded to pure annotations in Self version 3 because it "was found to be unworkable", partly because the protection mechanism could be easily circumvented due to Self's dynamic inheritance, which is also mentioned in the paper.) I also learned about a seemingly well-known JavaScript pattern where private data is modeled as capturing of local variables during object construction, but I find this scheme to be quite unpractical as it requires any method needing to access private slots needs to be effectively copied for each object clone, which defeats message delegation. Other than that, I haven't found anything concrete on the topic yet.

So I thought about the issue myself, and came up with an idea that I would like to share with you. Suppose an object is a collection of slots, each of which associates a name symbol with a value. It is possible to retrieve a slot's value from an object by sending it a message, "getSlot", with the name of the slot as argument. Now, further suppose that name symbols are themselves objects, and are unique: there are never two symbol objects which denote the same name. So, in fact, objects slots can be thought of as object-object (instead of string-object) associations. We could thus generalize: instead of special name symbols, "getSlot" could instead allow any object to act as slot key, making it possible to to associate any object with any other in the context of a specific object.

Now my idea: given the above, it is clear that in order to refer to a slot in an object, two things are needed: the object itself, and the slot's key object. This means that without a reference to the slot key object, it is impossible to access to corresponding object slot. In the simple case that all keys are name symbols, this is a trivial statement, as in most languages, it is possible to refer to any symbol from any context by the way of literals. But if slots are modeled as generalized object-object associations, it is possible to create a key object which is only available in the context of its creator, and which may be used to control access to the slot by passing it only to privileged parties. Thus, such a system would enable the programmer to use arbitrary objects as capabilities for accessing a slot, in the spirit of existing capability systems on the object reference level.

This feature could be used as a powerful way to encapsulate slots in any level of granularity. For instance, in a language with full block closures, one could write something like the following to define slots which are private to a specific set of object methods (Io/Smalltalk-like pseudo code):

o := Object clone

[
    priv := Object clone

    o foo := method [
        ...
        foo := o getSlot(priv)
        ...
    ]

    o bar := method [
        ...
        o setSlot(priv, "bar")
        ...
    ]
] value

(The [ ... ] value should signify that the code is run in a private local activation record to ensure that priv does not leak out to the surrounding namespace.) These methods could also grant other objects the right to access the slot by sending them the priv object, which would amount to something like a dynamic version of the C++ "friend" feature. Numerable other arrangements are thinkable.

What do you think of this idea? Is it sound? I know that this requires careful choices regarding the reflective features of a language with such a protection mechanism; for instance, it shouldn't be possible to enumerate all slot keys of an object (as in Javascript). But except for this, is there anything I have overlooked? I am sure I'm not the first one to have this idea. ;) Any feedback on this is very welcome!

P.S.: Lambda the Ultimate help me tremendously with my PLT research, so a big thanks to everyone who is posting here! You helped me a lot in the last years, and I am absolutely certain that you will continue do so. :)

I think I've seen that guy somewhere before, he sure sounds oddly familiar.

Summary
Mark S. Miller talks about the security considerations of JavaScript and how they are dealt with in ECMAScript 5 and the Caja project. He also mentions issues that have to do with HTML5 and compares the security characteristics of other languages like Java and Scheme.