[peter-fogg]

OK, let's talk about parsing.

The article claims that parsing isn't necessary with structured editing. We're working on some abstract data structure representing our language's syntax. This might be an AST, like any programming language in common use today, or maybe in the future we've thought up some better way to represent programming languages within the compiler/interpreter. Since we're working directly with the AST or whatever, we don't need to parse! We just do whatever actions the programmer wants do over on our data structure.

Now, let's talk about how parsing works in your language of choice in 2015. We're going to take a string, and we'll turn it into a representation of our program. If we're lucky, our language implementation isn't awful, and our parser will be a function from some sort of Unicode-encoded text into an AST. OK, maybe our input is ASCII or some other text encoding, but the point is the same. Either way, we're taking some keypresses from the programmer, and turning them into a data structure representing the program.

Let's abstract a bit. Maybe in the future we don't use keyboards. Instead, we have whatever peripheral you like. This peripheral is capable of sensing some sort of action from the user, and turning it into actions within the computer. So now, our parser is a function from some user action to a data structure representing the program.

This sounds an awful lot like "we just do whatever actions the programmer wants do over on our data structure". The question is, how do we figure out what the user wants? The answer is, we parse it! It doesn't matter if we're parsing text or not. We will always need some way of determining the programmer's intention from the signals we get through their peripheral device. Viewed through this lens, the camera requires a parser just as much as the keyboard does, just as much as the mousepad does, just as much as the microphone does. We will always need a way to convert the unstructured thoughts of a human programmer into the formal language of a compiler's internals. Regardless of what representation we choose for any part of this process, it's going to be subject to the article's quote:

> This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.

[nightski]

No. There is a large difference between parsing commands which affect the structure of a program and directly parsing the structure itself. For one, commands that affect the structure in an invalid way can be rejected. Second, commands can be stored so that a history of source code manipulations can be replayed (which while possible via text ala git is very lossy and subject to merge issues - as stated in the article). In addition, commands are limited by context. So when parsing the user's input we now have a limited context to work within greatly improving accuracy and also simplifying the input space of the user.

These are just a few of the reasons...