Hacker News Reader

Comment by westoncb | Hacker News Reader

I wrote an article on a relatively simple approach to building language systems with these properties titled, "How to Make View-Independent Program Models"[0]

I haven't had a chance to try an implementation yet, and maybe there's a reason why it wouldn't work, but I've been looking and haven't found it yet (maybe someone here will!).

[0] http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe...

View on HN

I think the challenge for systems like this is flexible editing -- the most natural way of making changes to source code often goes through "invalid" states which can't be represented as an AST (or as a path through a parser automaton).

I think that has been true for AST editors because they remain halfway in the traditional text-editing paradigm, which involves these invalid states because the granularity of the interface is single character operations, while the model you are specifying with those characters (the AST) doesn't recognize those units.

An alternative is to have the editor operate on language constructs rather than characters. Rather than parsing the program view in order to arrive at a model of your program, you arrive at a view by rendering the model in some way. But the key thing is the model always stays intact because the operations you perform on it through your editor are in terms of language constructs (e.g. a single action in your editor might be 'add property' or 'create class', which is ordinarily accomplished by typing out lots of characters that can hopefully be parsed into such things).

I believe in this approach, but making it usable is harder than it sounds. Once I tried watching myself program with this idea in mind. I realized I often start by typing methods which don't yet have a class, code fragments which don't yet belong to a function, even expressions which don't yet live in a statement and which refer to variables which not only don't yet exist but don't belong to any yet-existing class — maybe I'll pause half-way through writing the expression and start creating the class in another window.

So you pass through a lot of ill-defined states. For the IDE to keep up it would have to just represent explicitly "this is a code fragment which doesn't have a name", "this is a variable which isn't defined anywhere" and so forth.

Those states are only ill-defined on the assumption that you're entering text which will be parsed. You can still enter fragments when operations are in terms of language constructs rather than characters--you have just supplied a partial set of parameters to the construct, which you can go back and finish later.

Maybe the other part of this issue is expecting to use these potentially better editors in the same way we use text editors. I would bet different patterns of interaction would surface for the new editors which aren't obvious from our present standpoint.

Reply on news.ycombinator.com