Remembering the Future

Marc Hamann

The power of a name is that it is just a formal entity to which a value can be bound, but that can enter into logical relations and constraints before it is yet bound.

In the subtext demo (I didn't explore beyond that) you had to create a specific value first, and then you could could link it elsewhere. The fundamental concept of abstraction ( defining relationships or properties that exist independent of particular values ) is missing, except in the weakened form of copying a pre-existing relationship and plugging different values in it.

If a name only exists when it is already bound to a particular value, it isn't really a name, and you don't have real abstraction in your language.

Jonathan Edwards

I am in the process of unifying copying with linking, so that you can dynamically re-parent a structure based on a linked reference, which results in higher-order functions. I hope that will earn me some respect with the functional programming crowd.

There is more detail in the paper (see higher-order copying), but frankly there are still a lot of issues to resolve. Subtext is still very much a partial sketch of an evolving idea.

. . .

Some object that my links are just pre-bound names, but that is exactly the point. I have removed name binding from the language. Binding is completely up to the programmer (or metaprogram) to do in whatever way they like when the program is constructed, and is outside the language semantics. Attaching ASCII identifiers is an optional convenience. By eliminating name binding, you don't have to wait till compile-time or run-time to see what the links mean. This is crucial to seeing abstractions in code as living examples that adapt to their context.