TextBlocks MM Design Workshop 03.03.2011
From Furcas Wiki
Contents |
Agenda
- Current issues with TB MM
- Not always clear how text blocks are linked with domain model elements
- Not always clear how to find text blocks that document the construction of a specific model element or the application of a property / property init
- Choices of alternatives documented in text blocks in tricky ways. Does it need to be like that?
- Pretty-printer currently cannot decide whether an element is intentionally missing from a textual representation or has been added to the domain model, suggesting representation in text.
- Very Quick review of all properties of the TB MM. Will help to understand what it does and what it doesn't.
- Write down docstring if the meaning is unclear (e.g. isComplete?)
- Drop the property if it seems unessecary (e.g. the cached string)
- Brainstorming
- Initial redesign
- Discuss way to organize TB model helpers / helper classes. Some functionality is implemented in many places. Reuse is rare. (e.g. primitive template serialization)
- Is there a way that parser and pretty printer can share some code? Both seem to construct a TextBlocks model from an event trace.
- Derive and distribute actions
Meeting Minutes
Use Cases for Text Blocks Model
It's supposed to be a trace of the parser run and shall document the mapping from text to AST. This is important for incementally updating both, text blocks and AST models.
It also documents the property init executions. This is important for incrementally updating the property init values (using the OCL IA).
For text serialization a text blocks model represents all information required to produce a (potentially partial) textual view.
Partial features shall allow for a per-instance configuration whether all elements or just the explicitly selected shall be rendered in text. This calls for an additional flag on the parent text block containing the representations of the feature's elements. Additionally, the mapping (template) shall allow for a configuration option where mapping authors can choose what the default for the pretty printer for the partial feature should be: show all elements in the partial feature by default, or show none and let the user explicitly select, or render all if no text block exists yet but don't update automatically when new elements appear.
The text blocks model must be able to map a character position in the document to a token. Vice versa, a model element must be mappable to a character position in the document.
The text blocks model must be able to produce a character stream, e.g., to the lexer. The editor manipulates a copy of the text blocks model's tokens which are later fed to the lexer again. This can lead to a restructuring of the tokens.
Explanation of Text Blocks Models
Text blocks models are trees of TextBlocks and Tokens. There may be different versions of a text blocks model at one time. From a consistent ("reference" model version) text blocks model there may be a new ("edited") version which has updated token contents, based on document change events. These tokens may not necessarily be reasonably lexed but lead to the current text string. Between "reference" and "edited" text blocks model there are 1:1 otherVersions references linking these two text blocks models.
When the lexer starts, a 1:1 copy of the "edited" model is created which is called "current." The lexer operates on "current" and modifies it, producing a set of tokens that are again lexically consistent. New tokens always emerge from existing tokens and are associated with the same text block as the token from which they emerged. Tokens may also be deleted by the lexer. For new and deleted tokens, the otherVersions relation is no longer 1:1. The lexer will try to intelligently re-use existing tokens.
The parser operates on the "current" model and updates the TextBlocks elements. It uses the token elements produced by the lexer and assigns them to the TextBlocks elements produced / updated during the parser run.
If the lexer fails, the "current" version is deleted. Remaining are "edited" and "reference." If the parser fails, the "current" and "edited" and "reference" versions remain. If the parser run succeeds, the "current" version is renamed to the "reference" version and all other versions are deleted.
Invariants for text blocks model versions: the "reference" model has been successfully lexed and parsed. Property inits may still have failed. A "current" model that survived the lexer run guarantees correctly lexed tokens. Text serializations of "current" and "edited" are guaranteed to be equal.
Actions
[Axel] Introduce observer pattern for SyntaxRegistry where observers can register for change requests regarding tokens. The OCLQueryPropertyUpdater would then only produce a change request describing which token is to update. The actual update can then be performed by an adapted ShortPP which works on a token iterator telling the tokens to update. (Partly implemented; see TokenChanger interface; waiting for feedback on discussion mailing list.)
[Thomas] DocumentNode.otherVersions could be modeled as its own opposite.
[Thomas/Stephan?] Investigate best implementation for maintaining the version of each DocumentNode (in the node vs. on the root / syntax, ...). Compare read and write accesses.
[Sebastian] Set containment for ContextTemplate.contextTags in TCS.ecore.
[Sebastian] Remove startRow, startColumn, endRow, endColumn, commentsBefore, commentsAfter in textblocks.ecore and adjust stubs and wrappers.
[Thomas] Move correspondingModelElements from DocumentNode to TextBlock and make it a to 1 reference. Use this for referenceOnly templates. Decision whether to delete an element with the deletion of a TextBlock is then based on the referenceOnly attribute of the TextBlock's template.
[Thomas] Move referencedElements to LexedToken and change its cardinality to 0..1. Its value is only updated in the referenceBy case.
[Axel] Organize boolean case for forEach with no special rule but use when/as construct. Maybe define that the result of the forEach expression has to be object-typed. (Boolean case will just not be supported anymore. It can be emulated by producing a Collection(Boolean) as result of the foreach expression and then use "self" or "not self" as the when-clause.)
[Stephan] Directly reference SequenceInAlternative/Conditional elements from TextBlocks. (this also requires an update to the grammar generator and observer interfaces.)
[Thomas] Define explicit constraints over FURCAS metamodel(s). For example: Templates called by a forEach may not have a syntax contribution. A referenceOnly template may only refer to referenceOnly templates.
[Thomas] Remove TextBlockDefinition and make TextBlock directly reference Template.
[Axel] Rename ForEachContext to ForEachExecution and make it inherit from TextBlock. (Done)
[Thomas] Produce a TextBlock for each execution of a template. This means that also for Templates that have no syntax contribution, a TextBlock is created.
Future Discussions
- Sandbox concept for language prototyping --> having language definition and editor in the same IDE. See MPS as exmaple.
- A preview that runs the pretty printer with the currently crafted syntax should be rather easy to implement. One could open a reference model in it which would then be printed. It would be read-only but atleast one has instant feedback. (Stephan)
