Mutability Revocation

PostScript has MutabilityRevocation as a runtime feature, not statically checked: a container can be either +w or -w (chmod'able at will), and it's an error to try to change a -w container element. In other words, you can create a container, mutate it, and then when it's just how you like, make it read-only.

This is called MutabilityRevocation (a term I just coined; if someone knows a more standardized term in the literature, please ReFactor this page).

An example of TypeMigration.

Consequences:

• A good solution to the non-trivial construction problem (where an object must be constructed piece-by-piece; and this is difficult to do with a single constructor call).
  • However, this may expose a partially-assembled object to the world.
• Likely interferes with StaticTyping. Methods that used to work may no longer work suddenly, due to something done to the object somewhere else. Languages with DynamicTyping might not have this problem, assuming they always do the necessary checks (and don't cache away "OK, this operation is legal on this object").

Anything have it besides PostScript?

---

As a side note, Postscript permissions are extremely similar to Unix permissions: containers have read permission, write permission, and execute permission, and each can be turned on/off at any time dynamically.

There's an interesting interplay with other language features: the difference between a data array and a function is simply that the function is marked executable, while a data array is not.

This is one of the principles behind SelfLanguage, and it doesn't need permissions at all to achieve this.

Permissions are one of Self's principles, and it doesn't need permissions to achieve this? Say what?

Exactly what do you think is the difference between Postscript "execute on/off" versus Self's "execute on/off but this isn't a permission"?

---

Contributors: DougMerritt, ScottJohnson