Course "Domain-specific programming languages" (http://dsl-course.org). Developed by Mikhail Barash.

1. 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