The last several months I have been trying to make coherence deterministic, using what PL theoreticians call a type and effect system. The effect system is telling me to return to the tree data model of Subtext (which I had set aside as too complex), but with static types. Therefore I am redefining Subtext as a statically typed language, with classes and inheritance and so on. I have sketched this out, and it seems to magically resolve many of the complexities that were stumping me before.<\/p>\n
Why didn’t I see this before? Maybe I drank too much of the Self kool-aid. Subtext has always been a prototypical language like Self. That is an elegant idea, but static classes really are a handy way to impose structure on the chaos. That structure is needed to guarantee deterministic parallelism, and it also comes in handy in a lot of other places where you want to impose constraints.<\/p>\n
My next step is a precise description of typed Subtext, focusing on the data model. I may start off with a normal imperative semantics and add coherence in the subsequent step. I am going to use a textual syntax, since that is what people need and expect. Subtextuality manifests in that the syntax will require an IDE to be easily editable, since it is actually just a pretty-printing of an underlying code meta-model.<\/p>\n","protected":false},"excerpt":{"rendered":"
The last several months I have been trying to make coherence deterministic, using what PL theoreticians call a type and effect system. The effect system is telling me to return to the tree data model of Subtext (which I had set aside as too complex), but with static types. Therefore I am redefining Subtext as … <\/p>\n