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.
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.
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.
Is it really what you see is the best way or you just want to be able to demo something actually at Onward? Nothing personal, just asking.
I can’t make the OOPSLA deadline. My new resolution is to write a paper only after first doing a presentation.
Does that mean you can make the OOPSLA video presentation deadline? That requires a 4 page paper, though…
I think you’d be better off with Haskell-like type classes or Scala-like implicit conversions than with inheritance. Inheritance causes way too much problems.
Agreed. Subtext classes are essentially interfaces, where inheritance works. Now that you mention it, I should probably just call them interfaces instead.
I am encouraged by the spreading dissatisfaction with inheritance. I always thought it was a hack – a language implementation mechanism masquerading as a feature.
Can you clarify your comment on inheritance?
I would say that the biggest problem with “inheritance” in most (all?) object-oriented third-generation programming languages is the notion of IS-A data modeling and categorizing operators like instanceof(reference) as “object-oriented”, which is an ontology error and also goes against the flexibility of using objects to perform simulations.
To finish my thought above, please see Wegner and Zdonik’s paper “Inheritance as an incremental modification mechanism, or what like is and isn’t like” http://portal.acm.org/citation.cfm?id=60605
This paper is different from the Liskov Substitution Principle paper, and discusses safe substitution mechanisms in object-oriented languages, thus avoiding thorny issues with visibility modifiers. There is still the fact that reusing behavior requires a trustworthy mechanism for reuse, e.g. using separation logic such as that advocated by Matt Parkinson, e.g. the paper “Separation logic, abstraction and inheritance” — although Matt’s abstract starts off in the first sentence with a classification error (“Inheritance is a fundamental concept in object-oriented programming”), the rest of the paper is quite good.
A denotational semantics of inheritance is much cleaner than the messy operational semantics given in most object-oriented third generation languages. Please see William Cook’s 1989 Ph.D. thesis for motivating lesson. This, of course, does not solve open-closed problems in code sharing and reuse. Inheritance in most modern languages also tends to imply hiding component fragments, rather than directly exposing a component fragment and allowing the programmer to “import” component fragments (a’la Newspeak and Invasive Software Composition).
I am not even sure how one would desire to compare Haskell’s type classes, implicit conversions, and property acquisition (inheritance, or “code sharing”). It just seems like a category error.
Subtext, from what I’ve seen, uses a prototype-model for reuse. I would argue this model lends itself well to first-class copy-and-paste, and essentially is based on component fragments. The flaw with all previous prototype models, in my eyes, is that they assume you should start from a base prototype. This appears to conflate the design intentions of ADTs and Objects.
Just 2 cents about stuff I’ve been thinking about lately.
Prototypes are elegant, but they may have been a mistake. I am now rephrasing subtext with real types, which I am finding simplifies a lot of problems. However I don’t want to get dragged into the theoretical quagmire of inheritance. If it takes a William Cook to understand it, it doesn’t belong in a programming language.
I am pretty sure the fundamental problem with inheritance is the compilation model, e.g. “imports” using source code *files* as dependencies; the essence of Braha’s arguments for modularity in Newspeak. I would put Braha, Cook, Kay and Steele all on the same level, so Braha is-a Cook to understand this souffle, and is baking that souffle into Newspeak. Wadler wrote a blog post about this; he said there is no doubt in his mind Braha is right, and the remaining question is how to develop a type system for Newspeak’s way of thinking.
Something to debate about in the future, but not now.
RE: “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.”
I understand this to mean that certain regions of code are both read and written by an IDE. I think this is a right approach – allowing a sort of WYSIWYG coding but without hindering the ability for other editing tools to get involved.
RE: “Subtext has always been a prototypical language like Self.”
Your decision to use ‘objects’ is about handling IO, not types or anything else. And stateful IO is fundamentally about maintaining a condensed history so that you can avoid time-space leaks that arise if you use the full history.
Based on your 2009 October ‘Onwards!’ video, my first impression was that an IO model based on functional-reactive programming would be very appropriate. You allow first-class functions (schematic tables that can input and output partial applications of functions as first-class values) and disciplined use of continuous ‘time’ as a monotonic quantity allows you to garbage-collect historical inputs and outputs – while implicitly maintaining a condensed history, just as you would for an explicitly stateful program. A discipline for using ‘time’ could be statically enforced in a dedicated FRP language (similar to how it is enforced in Dedalus or Timed Concurrent Constraint programming).
Of course, a ‘global clock’ doesn’t scale effectively to open or distributed systems. That little fact has kept me from pursuing the denotational FRP approach for my goals. But, since your alternative – coherence – requires a ‘global scheduler’ regardless, I suspect FRP could be made to work for Subtext.
FRP with Schematic Tables could be sweet.