Projectional editing
- 2. Projectional editing source-based editing system projectional editing system program defined using a textual representation can be read and edited with any text-editing tool source code key representation of programtext representation of underlying model read and edited using special environment semantic model key representation of program can be projected into different representations program text diagrams tables forms
- 3. Equation Editor semantic model syntactic projection placeholder “smooth” editing MVC pattern model projection edited projection projection model editor transforms text “sin” to projection of sine “^” is transformed to projection of exponentiation placeholder Microsoft Word
- 4. Scratch placeholder editing moving blocks filling placeholders placeholder programs always have correct structure impossible to have wrong structure semantic analysis context conditions e.g., type matching have to be implemented code generation transform model to code
- 5. Projectional editing projectional editing user edits AST representation of code directly “MVC applied to code” editor mimics behavior of a text editor to some extent user sees text user edits text it’s an illusion projection of AST abstract syntax tree – logical representation of code user sees table user edits table user sees graphics user edits graphics
- 6. Projectional editing top-down editing select a placeholder bottom-up editing select desired concept from a menu similar to top-down editing type something that would identify some concept Content Assist in Eclipse start with a space that is already occupied select something to augment it Word doesn’t have drop-down menus for concepts either by typing or by selecting from menu special actions copy-paste copy entire subtrees
- 7. Syntax trees and semantic analysis int square(int x) { return x * x; } original AST separate leaf node for every x occurrences refer to the same variable after parsing requires semantic analysis does not require parsingprojectional editing AST is “finalized” by construction a variable can be renamed and new name is propagated to all nodes of AST tt should be the same node abstract syntax tree
- 8. Parsing and language evolution parsing C introduced new keywords class and template complicates design of languages int template = 1; int class = template + 5; valid C code invalid C++ code can’t add new keywords without breaking existing codenew version of a language JavaScript allows keywords to be used as field names of an object each new syntactic construct must be evaluated before being added
- 9. Parsing vs. projectional editing int class = template + 5; template= + ;classint 5 <expression>= ;<name>int <variable declaration> = ;<name>int <variable declaration> <expression> <left> + <right> textual projectional concept trigger for concept fixed parts – in grey placeholders – in yellow trigger editor always has access to AST current concept containing concept <name>int name: string any string can be used here that string will be associated with that variable name concepts can also be chosen from a menu user’s intention
- 10. Benefits of projectional editing textual form of code only meant for the programmer no need for curly braces, semicolons to separate constructs projectional editing allows languages to evolve but it is unambiguous languages can be combined with each other set of node types that can be added to ASTnew DSL nodes are selected explicitly no ambiguities in AST users of DSL communicate their exact intentions to the editor textual syntax can look ambiguous